Announcement

Collapse
No announcement yet.

Wayland Security Module Gets Prototyped By Tizen

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Wayland Security Module Gets Prototyped By Tizen

    Phoronix: Wayland Security Module Gets Prototyped By Tizen

    Covered last year on Phoronix was LibWSM: Wayland Security Modules For Better Wayland Security. The Wayland Security Module library was presented last year at XDC2014 as a way of bettering the Wayland compositor security. While back then it was talked about as a possibility, a Tizen developer has been working on the WSM code to make it a working reality...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Security module written in C is bad joke. C software can't be safe because there are too many possibilities for security bugs like buffer overflow especially with lax development process.

    Comment


    • #3
      Originally posted by JS987 View Post
      Security module written in C is bad joke. C software can't be safe because there are too many possibilities for security bugs like buffer overflow especially with lax development process.
      Yup. I'm hoping after Rust matures enough (let's say version 2.0), it will be adopted by the Linux kernel community and that they would start slowly replacing parts of the kernel with Rust. However, it probably shouldn't even be *all* of Rust, but only some highly secure parts of it, like how car manufacturers use MISRA C.

      Comment


      • #4
        Originally posted by Krysto View Post
        Yup. I'm hoping after Rust matures enough (let's say version 2.0), it will be adopted by the Linux kernel community and that they would start slowly replacing parts of the kernel with Rust. However, it probably shouldn't even be *all* of Rust, but only some highly secure parts of it, like how car manufacturers use MISRA C.
        Considering they have not even adopted C++, and well written modern C++ avoids almost all of C's pitfalls (use references rather than pointers, smart pointers instead of new / delete or malloc / free, strings rather than char arrays, standard containers, lambdas, private data members, etc) I doubt many of these core system projects that really need a secure language will move away from the most insecure language there is.

        Comment


        • #5
          I'm starting to think that a conversation about programming languages is a lot like a post on the internet about hard drives. No matter what hard drive is being discussed, someone will pipe up saying that Seagate / WD / Samsung hdds are the worst and that they've had seventy-twelve of them fail in the last month. 'That manufacturer is just awful when it comes to building hard drives' they'll say, doesn't matter which manufacturer, someone's always there to testify to their lacklustre quality.

          I'm sure if it was written in Rust or C++ then someone would be in here bemoaning that fact and saying 'why oh why couldn't they have written it in C, it's the standard and what everything like this should be written in'.

          Personally, I think it should have been written in Pascal or object-oriented Javascript

          Comment


          • #6
            Originally posted by zanny View Post
            Considering they have not even adopted C++, and well written modern C++ avoids almost all of C's pitfalls (use references rather than pointers, smart pointers instead of new / delete or malloc / free, strings rather than char arrays, standard containers, lambdas, private data members, etc) I doubt many of these core system projects that really need a secure language will move away from the most insecure language there is.
            In trying to be everything for everyone, C++ built quite a reputation as a systems language for things too complex for C to be feasible ("Democracy is the worst system of government...except for everything else"). I'm not at all surprised that they'd avoid it when they're still capable of success with C.

            With its current lead-up-to-1.0 focus on shrinking the core language syntax to be as concise as possible and no more (pushing complexity to stdlib or 3rd-party crates when feasible), Rust feels much more C-like than C++ does, despite the combination of expression-oriented syntax, match constructs, destructuring assignment, lifetimes, RAII, etc. giving it what the tutorial calls "a functional flavour".

            ...plus, it's designed to interoperate with C easily and its alternative to the C++ object system is much easier to reason about. (And, the use of phantom types in generics, which are considered by compile-time checks but optimized out, allows you to delegate things like "pixels + inches = ERROR" or "sanitized_text.some_append_function(raw_input ) = ERROR" to the compiler)

            Comment


            • #7
              Cool

              I hope it gets hooked up to swc/velox and not just the "big" clients like weston gnome, kde, enlightenment, ...

              Comment


              • #8
                Future of DRM?

                In the future I won't be able to take screenshots?
                I won't be able to record/capture video streams?

                Comment


                • #9
                  Originally posted by uid313 View Post
                  In the future I won't be able to take screenshots?
                  I won't be able to record/capture video streams?
                  Only a limited number of applications will have such special access.

                  Comment


                  • #10
                    Originally posted by uid313 View Post
                    In the future I won't be able to take screenshots?
                    I won't be able to record/capture video streams?
                    What...? Uid, if thats the take away you took you obviously didn't read the article or the older article on Wayland Security Modules.

                    This is about restricting access to your video camera / microphone / screen shots capability / screen contents (for color picker) and other devices or capabilities that could be exploited by not-so-nice applications. Want any random app to be able to turn your webcam on and upload pics of you? Or do the same with your microphone? Or what about a virus that silently takes screenshots of your banking web page? If anything tries to access those (or other) capabilities you get a big "Allow / Disallow" alert with the name of the binary / application and what it tried to access.
                    All opinions are my own not those of my employer if you know who they are.

                    Comment

                    Working...
                    X