Announcement

Collapse
No announcement yet.

AppArmor Is Going Into The Linux 2.6.36 Kernel

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

  • AppArmor Is Going Into The Linux 2.6.36 Kernel

    Phoronix: AppArmor Is Going Into The Linux 2.6.36 Kernel

    James Morris has outlined a preview of the security subsystem changes he is currently carrying in his security-testing-next branch of the Linux kernel that he plans to have Linus Torvalds pull into the next kernel development cycle for Linux 2.6.36. The big change in the kernel security world is that AppArmor is being planned for integration into the Linux 2.6.36 kernel...

    http://www.phoronix.com/vr.php?view=ODQ2Ng

  • #2
    Does anyone know why some distros choose AppArmor over SELinux? Is it better?

    Comment


    • #3
      I found this:
      http://www.novell.com/linux/security...omparison.html
      looks like AppArmor to SELinux is what inotify is to dnotify (that is better and easier).

      Comment


      • #4
        Some of the major distributions that have backed AppArmor as part of their security model is Ubuntu, openSUSE, and Mandriva.
        Is?

        TenTenTen

        Comment


        • #5
          Asking if AppArmor is better than SELinux is like asking if Linux is better than OpenBSD. They solve different problems. Over at lwn.net there is a very nice discussion with an author of the TOMOYO project about advantages and disadvantages.

          Comment


          • #6
            Originally posted by chithanh View Post
            Asking if AppArmor is better than SELinux is like asking if Linux is better than OpenBSD. They solve different problems.
            That's a half truth, there are common problems they solve in different ways and as explained in the link above from Novell - AppArmor is certainly better in those cases cause it's simpler and easier.

            Comment


            • #7
              grsecurity > *

              Comment


              • #8
                Originally posted by cl333r View Post
                Does anyone know why some distros choose AppArmor over SELinux? Is it better?
                A lot of people don't like SELinux because it's difficult to work with. I think a lot of people end up disabling it on Fedora.

                Comment


                • #9
                  I hate profiling because it's practicaly useles.
                  If apps would ship with their own profile file that complies with a freedesktop standard that doesn't exist then it would be of some use I guess.

                  BTW you may disagree with me.

                  Comment


                  • #10
                    Originally posted by pvtcupcakes View Post
                    A lot of people don't like SELinux because it's difficult to work with. I think a lot of people end up disabling it on Fedora.
                    They used to. Most of the time now it's unnecessary. This is due to the 'targetted' policy implemented by Fedora/Redhat by defualt. This policy is designed for mild server situations were your only worried about external threats over the network. It allows local user logins to do pretty much whatever they want within the traditional 'DAC' security framework. Targetted policy is worthless if your goal is to increase the protection from local user accounts.


                    ================================

                    SELinux is complicated in the extreme because implementing a full fledged MAC system is itself extremely complicated. I can set up a SELinux machine so that if your user does not have security clearance you will not just be denied access to 'top secret' files on the machine... it would be impossible for you to even detect their existence. Even if you knew their names and know were they would be at, you still could not prove they existed, unless you try a physical attack on the machine (break into the building and steal the harddrive).

                    Other security mechanisms such as Toyomo, AppArmor, SMACK, and the like are trading capabilities for usability. There is nothing they can do that SELinux cannot do, but there is a lot of things that SELinux can do that they cannot.

                    If your implementing high security system for government agency or hardcore banking system then your a idiot to use anything other then Selinux.... It was designed specifically for those purposes.

                    If your goal is to prevent your user account being hacked because Adobe's flash plugin sucks then AppArmor is your friend.

                    Comment


                    • #11
                      Originally posted by drag View Post
                      They used to. Most of the time now it's unnecessary. This is due to the 'targetted' policy implemented by Fedora/Redhat by defualt. This policy is designed for mild server situations were your only worried about external threats over the network.
                      And the lower level access to RAM, which is blocked and in turn makes it useless to run Wine. But not that that matters because Wine does not work by default on 64bit images (some linker crap, don't know the details).

                      Besides that eveything that one compiles on their own will simply run, unless you profile it and somehow miss that crucial and rarely apearing system call and everything crashes.

                      Comment


                      • #12
                        Originally posted by V!NCENT View Post
                        And the lower level access to RAM, which is blocked and in turn makes it useless to run Wine. But not that that matters because Wine does not work by default on 64bit images (some linker crap, don't know the details).
                        I've been trying to understand what you're saying, but it appears to be gibberish.

                        Comment


                        • #13
                          Originally posted by movieman View Post
                          I've been trying to understand what you're saying, but it appears to be gibberish.
                          Latest Fedora instal. Wine from Fedora respository installed. Steam installer for Windows.

                          You install Wine and all of it's own apps like notepad and regedit work just fine. But then you decide to install a game and run it.

                          SELinux pops up, saying that it has denied Wine to acces some lower level (RING) memmory and Wine crashes.

                          The SELinux reports tells you how unfortunate this is and that you can grant Wine access if you losen up the permissions with some kind of command. It warns you though that there might also have been some potential malware, disguising itself as Wine that wanted to have lower level memory acces (OR SOMETHING).

                          Okey fine. You realy want to see that dansing rapport, I mean play some game and you feel like lowering security is OK so you take of your tinfoil hat and execute that command as root.

                          You go back to the terminal and launch that game you have been desperately wanting to play for your entire life.

                          Not very much planctime passes before Wine crashes... again! Pissed of as you are you are going to Google it.

                          It being:
                          "wine: cannot find L"C:\\windows\\system32\\wineboot.exe"

                          You find out that, althought the previous error message you got, Wine 64bit, being installed when you yum install wine on 64bit images of Fedora, doesn't link to /usr/bin/wine for some wierd reason.

                          Fantastic. Althought by reproducing it again I found the workaround on Google now. So....

                          Comment


                          • #14
                            Originally posted by V!NCENT View Post

                            Okey fine. You realy want to see that dansing rapport, I mean play some game and you feel like lowering security is OK so you take of your tinfoil hat and execute that command as root.

                            You go back to the terminal and launch that game you have been desperately wanting to play for your entire life.

                            Not very much planctime passes before Wine crashes... again! Pissed of as you are you are going to Google it.

                            It being:
                            "wine: cannot find L"C:\\windows\\system32\\wineboot.exe"

                            You find out that, althought the previous error message you got, Wine 64bit, being installed when you yum install wine on 64bit images of Fedora, doesn't link to /usr/bin/wine for some wierd reason.

                            Fantastic. Althought by reproducing it again I found the workaround on Google now. So....

                            Fedora 13, 64-bit release. yum install wine. Turn off the boolean in SELinux via SELinux troubleshooter. Just point and click. Installation via Wine works just fine. Just tried yesterday.

                            Comment


                            • #15
                              Originally posted by RahulSundaram View Post
                              Fedora 13, 64-bit release. yum install wine. Turn off the boolean in SELinux via SELinux troubleshooter. Just point and click. Installation via Wine works just fine. Just tried yesterday.
                              Did exactly that. Steam installs but doesn't run.
                              Code:
                              wine: cannot find L"C:\\windows\\system32\\wineboot.exe"
                              err:process:start_wineboot failed to start wineboot, err 2
                              CellID: Fetching server list from CSDS. . .
                              fixme:process:SetProcessShutdownParameters (00000100, 00000000): partial stub.
                              err:ntlm:SECUR32_initNTLMSP ntlm_auth was not found or is outdated. Make sure that ntlm_auth >= 3.0.25 is in your path.
                              err:ntlm:SECUR32_initNTLMSP Usually, you can find it in the winbind package of your distribution.
                              Not exactly working here.

                              Comment

                              Working...
                              X