Announcement

Collapse
No announcement yet.

Wayland Security Module Gets Prototyped By Tizen

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

  • #11
    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.
    Because java, python, ruby, php, javascript, etc never had vulnerabilities. LOL. In C security depends on code quality and not a Turing-complete machine.

    Comment


    • #12
      Originally posted by Ericg View Post
      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.
      Thanks for actually know what you are talking about! However, both Steve and I are not fans of constantly asking the user and we proposed multiple ways for avoiding this terrible UI!

      Comment


      • #13
        Originally posted by M?P?F View Post
        Thanks for actually know what you are talking about!
        Expectation's bar is a little low? :P


        Originally posted by M?P?F View Post
        However, both Steve and I are not fans of constantly asking the user and we proposed multiple ways for avoiding this terrible UI!
        Besides just "Allow / Disallow / Allow And Remember" ?
        All opinions are my own not those of my employer if you know who they are.

        Comment


        • #14
          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.
          C software can be safe, it's just more difficult than other languages as it places more responsibility on the programmer. The kernel and openSSH come to mind as examples of this.

          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.
          There's no way the kernel devs will adopt Rust - they're still using C89. They haven't even adopted C99, there's no way they'd consider a completely different language; the cost of porting the entire codebase would be massive.

          Furthermore, while rust is a nice language, you can't just port C programs to it, as you need to specify object lifetimes when defining pointers. The difficulty of doing so after the fact is analogous to that of porting code from a weakly typed language to a strongly typed one. It's a great language for new projects, but I can't see anyone porting an existing project to it. Even Mozilla chose to write a completely new browser engine (Servo) in it rather than port their existing one.

          Comment


          • #15
            Originally posted by rdnetto View Post
            C software can be safe, it's just more difficult than other languages as it places more responsibility on the programmer. The kernel and openSSH come to mind as examples of this.



            There's no way the kernel devs will adopt Rust - they're still using C89. They haven't even adopted C99, there's no way they'd consider a completely different language; the cost of porting the entire codebase would be massive.

            Furthermore, while rust is a nice language, you can't just port C programs to it, as you need to specify object lifetimes when defining pointers. The difficulty of doing so after the fact is analogous to that of porting code from a weakly typed language to a strongly typed one. It's a great language for new projects, but I can't see anyone porting an existing project to it. Even Mozilla chose to write a completely new browser engine (Servo) in it rather than port their existing one.
            Could be a good language for new drivers though. It's got good C interop and drivers seem to be the biggest source of bugs in any major kernel these days.

            Also, one of the reasons Servo is a from-scratch solution is that it's got a fundamentally different architecture. (With the help of Rust, how parallel can we go?)
            Last edited by ssokolow; 11 March 2015, 02:42 AM.

            Comment


            • #16
              Originally posted by ssokolow View Post
              Could be a good language for new drivers though. It's got good C interop and drivers seem to be the biggest source of bugs in any major kernel these days.

              Also, one of the reasons Servo is a from-scratch solution is that it's got a fundamentally different architecture. (With the help of Rust, how parallel can we go?)
              While it's technically possible, it wouldn't make sense practically. Drivers are usually written with the intention of being merged into the mainline kernel (in order to lower the maintenance burden), but I doubt a module written in Rust would be accepted.

              As for drivers being the source of most bugs, that's because drivers comprise more than half of the kernel. Taking a quick look at my copy of 3.19, the drivers folder is the largest at 331 MB, followed by arch at 129 MB (the total size is 645 MB). It's also the part of the kernel with the most development going on - new devices are released at a much faster rate than architectures or file systems. Realistically, any subsystem with a lot of active development is going to have bugs, regardless of language.

              Comment

              Working...
              X