Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Security Operating Systems Software Government Linux News

How the NSA Took Linux To the Next Level 172

An anonymous reader brings us IBM Developerworks' recent analysis of how the NSA built SELinux to withstand attacks. The article shows us some of the relevant kernel architecture and compares SELinux to a few other approaches. We've discussed SELinux in the past. Quoting: "If you have a program that responds to socket requests but doesn't need to access the file system, then that program should be able to listen on a given socket but not have access to the file system. That way, if the program is exploited in some way, its access is explicitly minimized. This type of control is called mandatory access control (MAC). Another approach to controlling access is role-based access control (RBAC). In RBAC, permissions are provided based on roles that are granted by the security system. The concept of a role differs from that of a traditional group in that a group represents one or more users. A role can represent multiple users, but it also represents the permissions that a set of users can perform. SELinux adds both MAC and RBAC to the GNU/Linux operating system."
This discussion has been archived. No new comments can be posted.

How the NSA Took Linux To the Next Level

Comments Filter:
  • by Shuntros ( 1059306 ) on Sunday May 11, 2008 @11:14AM (#23369580)
    SElinux alone is an utter pain in the ass to work with, hence many Linux admins simply switch it off.

    Extensions such as AppArmour (formerly known as SubDomain), are what people should be embracing in order to make practical use of this excellent technology. Whilst using the same kernel hooks, AppArmour allows you to "snapshot" an application's activity and build a ruleset which can then be applied to the process. Much easier than titting around with SElinux policies forever and a day...
    • by FurtiveGlancer ( 1274746 ) <.moc.loa. .ta. .yuGhceTcoHdA.> on Sunday May 11, 2008 @11:37AM (#23369740) Journal

      utter pain in the ass to work with....

      Long ago, in the days when MLS was just the holy grail, Harris Corporation created the first A1 rated Multi-Level Secure computer system. I can't recall the name given to it, BlackHawk or something overblown like that. It was secure, but utterly unusable. According to some early testers I knew, it took more than 10 minutes just to log on. The command line took, on average, 5 minutes to respond to the simplest command. There were no policy templates, so all permissions and access lists had to be entered manually.

      SELinux doesn't look quite so bad in that light, now does it?

      • Re: (Score:2, Insightful)

        by Anonymous Coward

        utter pain in the ass to work with....

        Long ago, in the days when MLS was just the holy grail, Harris Corporation created the first A1 rated Multi-Level Secure computer system. I can't recall the name given to it, BlackHawk or something overblown like that. It was secure, but utterly unusable. According to some early testers I knew, it took more than 10 minutes just to log on. The command line took, on average, 5 minutes to respond to the simplest command. There were no policy templates, so all permissions and access lists had to be entered manually.

        SELinux doesn't look quite so bad in that light, now does it?

        Yeah, yeah, yeah and it took years to calculate by hand before computers and months to travel any distance before airplanes. So what's your point?

        SELinux is a pain in the ass. Your comparison is meaningless.

      • Re: (Score:3, Funny)

        I guess when the project failed, all the programmers were snapped up by Micro$oft to work on their Vista project!
      • by mrsteveman1 ( 1010381 ) on Sunday May 11, 2008 @06:15PM (#23372548)
        mister please don't make me use that thing, i promise i'll be real good! and i won't complain about selinux or nothin!
      • by toddestan ( 632714 ) on Sunday May 11, 2008 @09:54PM (#23373882)
        According to some early testers I knew, it took more than 10 minutes just to log on. The command line took, on average, 5 minutes to respond to the simplest command.

        Well, you can get the same experience now, thanks to Symantec Antivirus. Well, except for the whole actual security part.
      • by RKBA ( 622932 )
        Yes, but that was before the computer industry switched from mechanical relays to vacuum tubes. ;-)
    • Re: (Score:3, Informative)

      by TheLink ( 130905 )
      Yeah and we need some thing like "template sandboxes" on top of something like AppArmor.

      http://lists.opensuse.org/opensuse-bugs/2007-09/msg02994.html [opensuse.org]

      https://bugs.launchpad.net/ubuntu/+bug/156693 [launchpad.net]
    • by Znork ( 31774 ) on Sunday May 11, 2008 @12:17PM (#23369970)
      SElinux alone is an utter pain in the ass to work with, hence many Linux admins simply switch it off.

      I used to think so, but IMO, around FC7, F8 and RHEL 5 (ie, last year) the tipping point was reached. setroubleshoot and the tools around it are verbose to the point of telling you what to type so it's neither a problem noticing that there is an selinux denial nor any problem finding out what to do about it anymore.

      Many integration problems (applications and libraries doing funky stuff they plain shouldn't be doing, something not unique to selinux) have also been fixed at the appropriate places, leading to far fewer failures.

      Switching to MAC security has historically always been a serious pain in the ass (to the point where admins may have been better off implementing security by lack of mains power), but considering how painless it's gotten now I'd say whining about SElinux today says more about the admin than the software...
      • by HuguesT ( 84078 )
        Agreed, I have SELinux fully on with F8, I do notice a few messages from time to time, which I usually correct following the instruction given by SETroubleshoot, and all is well so far.

        I'm not positive my system is any more secure than if it were off, but at least I don't get angry and dismissive about it.
        • Agreed, I have SELinux fully on with F8, I do notice a few messages from time to time, which I usually correct following the instruction given by SETroubleshoot, and all is well so far.

          I've wanted to use it since 2004 or so (back when I was running Gentoo), but while the core functionality was there, I wasn't up to the task of dealing with it.

          When we started switching boxes over to CentOS 5 (back in 2007), it came with SELinux enabled out-of-the-box in "targeted" mode. To me, that was the tipping poin
      • This illustrates the point that the problem with selinux is the lack of useful userspace tools. This is pretty much the area in which redhate has always excelled. They have the best VM management tool too.

        I think I'll be waiting another year or two to move on to selinux. I've tried to jump on it a couple times now, and for the most part, when I try to follow a guide the guide turns out to be shit.

    • by zrq ( 794138 ) on Sunday May 11, 2008 @12:18PM (#23369976) Journal

      .. hence many Linux admins simply switch it off.

      Fine by me.
      Means that when it becomes mainstream, anyone who is familiar with how to configure and use it will be in high demand.

      • by gaspyy ( 514539 ) on Sunday May 11, 2008 @01:30PM (#23370392)

        Means that when it becomes mainstream, anyone who is familiar with how to configure and use it will be in high demand.

        If no one's using it, how will it become mainstream?

        • Re: (Score:3, Interesting)

          by mosinu ( 987941 )

          Means that when it becomes mainstream, anyone who is familiar with how to configure and use it will be in high demand.

          If no one's using it, how will it become mainstream?

          Quite simple really; Government mandate. Some agency will mandate it or make it part of some policy. From there it will spread into private sector via companies that do business with said agency. The Agency I work for is already doing just such a thing for new projects. Any company that is running Linux by contract has to secure their system through multiple methods; including SELinux.

    • by Z00L00K ( 682162 ) on Sunday May 11, 2008 @12:27PM (#23370020) Homepage Journal
      The concept of SELinux is good, but it isn't very friendly for the system administrator and the developers.

      A toolkit that allows for easy integration of new applications into SELinux and adaptations of already defined applikations would be useful. There are some around, but none are really good. The best would be if SELinux could allow for a "learning" mode for a single application in addition to the modes it has. Something like the Zonealarm firewall that is a bit noisy in the beginning, but as soon as it has learned what's permitted it goes silent. This will of course require a user-space application listening to the SELinux events. So a mode that allows SELinux to be permissive for a single application while strict for the rest of the system would be a nice thing.

      One common problem that I have experienced is that databases like MySQL are defined in SELinux, but it's very common that the data storage is going to be relocated in a production environment. This is a cumbersome process that costs a lot of work and pain.

      Another problem is the issue of semantics involved. It's not always clear and takes a lot of time to get familiar with.

      And still - SELinux is a "static" security measure, which only controls the permitted access between application and resource. It doesn't consider any frequency or volume. For example - a mail program may do a limited number of connections to port 25 per second, which is a normal situation, but if a higher frequency occurs that means that there may be a problem that has to be checked. OK - It's not easy to be intelligent about things like this, but system behavior pattern is a critical point in security too.

      So from a view of security SELinux is still only a step on the way, the threats of tomorrow has to be predicted and handled. This means that SELinux has to be a lot easier to work with for the average person to allow it to become a wide-spread security base.

      • by init100 ( 915886 )

        One common problem that I have experienced is that databases like MySQL are defined in SELinux, but it's very common that the data storage is going to be relocated in a production environment. This is a cumbersome process that costs a lot of work and pain.

        Is it? You only have to make sure that the new location has the same security context as the old one, which takes one simple command. Hardly a "cumbersome process".

        • by Z00L00K ( 682162 )
          Well - if you want the system to know about your new filesystem, e.g. "/db" and the database directory/files there so it can process them during a relabeling process you can't just change the security context of the files/directories. You will also edit the SELinux configuration files to tell that the files in that location shall be relabeled to the specific label you select whenever requested.

          And to add to this - if you have a new filesystem, the root of that filesystem has to have an appropriate label t

      • by WuphonsReach ( 684551 ) on Monday May 12, 2008 @07:25AM (#23376494)
        The best would be if SELinux could allow for a "learning" mode for a single application in addition to the modes it has.

        Read up on "seaudit" and creating custom profiles.

        (I still think the process could be a bit more human-friendly, but the tools do exist.)
        For example - a mail program may do a limited number of connections to port 25 per second, which is a normal situation, but if a higher frequency occurs that means that there may be a problem that has to be checked. OK - It's not easy to be intelligent about things like this, but system behavior pattern is a critical point in security too.

        Things like that are better handled in IPTABLES, or in the application itself. Those do not fall under the purview of SELinux which is about controlling access to the resource (not rate limiting or rationing out a resource).

        • by Z00L00K ( 682162 )
          Just an example - doesn't have to be a network resource - it can be file I/O, a socket, a shared memory or a device too. In those cases iptables isn't sufficient.

          As for what I wrote - I wanted just the single application to be in learning mode, not the whole system. A slight difference that has an impact for developing larger system solutions.

    • by lkcl ( 517947 ) <lkcl@lkcl.net> on Sunday May 11, 2008 @12:36PM (#23370086) Homepage
      if you believe that selinux is "an utter pain in the ass" then you have misunderstood what selinux is for. selinux is specifically designed to be able to PROVE that an application is secure, using formal mathematical analysis (of the policy files).

      [ the principle on which selinux works is that when you change "security context", it doesn't matter a damn if you were "god" before, you're now starting from scratch with zero permissions in the new context unless otherwise specified. this is best illustrated with an example of when you go into a military environment, they take your ID badge away from you and issue you with a temporary one that is only relevant inside that building. you can't even leave the building without that temporary badge, and it's been coded to only let you go to the toilet and into the rooms that are associated with your specific purpose for being in that building. and of course, if you forget to get your permanent ID back once you _do_ leave, you'll find it very difficult to get out the country! ]

      one of the "rules" that GCHQ and the NSA follow is that it is perfectly acceptable for something to be "insecure" as long as you KNOW that it's insecure: you can then provide a workaround or a fix to ensure that the security vulnerability is never exploited.

      the one thing that you absolutely absolutely must not ever have is a situation where you don't KNOW whether something is "secure" or "insecure".

      so if AppArmour has wonderful automated rulesets that are impossible to analyse...

      the thing about selinux is that policies require that you understand the source code and what the application is doing. for example, one of the guidelines is that applications should use exec rather than fork, because that provides total privilege separation, obviously, between tasks. fork() does not provide such a complete level of privilege separation, and so up until quite recently there was absolutely no way in selinux to even step into a separate security context on a fork() - it just... wasn't ... even ... remotely worth considering.

      however, it turns out that there were some specific instances why stepping into a different security context on fork() is actually useful (such as in samba) and so it was added in. due to the circumstances under which this could be thoroughly abused, it was decided that it should be provided only via an explict selinux function call (usually, you can just provide an selinux policy statement without any code modifications).

      • Re: (Score:2, Interesting)

        by jxxx ( 88447 )
        Maybe I'm missing something here, but fork() and exec() do different things. I don't see how one could be used as a general purpose replacement for the other. Do you mean fork followed by exec instead of system()?
        • by lkcl ( 517947 )
          yes i think i do :) [mean fork() followed by exec()].

          as opposed to just fork() which then shares some resources and continues to use them - e.g. file handles etc.
      • by sjames ( 1099 ) on Sunday May 11, 2008 @04:49PM (#23371882) Homepage Journal

        None of that is the problem. The problem is in the WAY the access is specified by slicing and dicing the namespace to assign a security context to each object.

        If I write an app that needs to access JUST ONE file in /etc and other apps already access it and a few more under a common context, I have two choices. I can allow my new app carte blanche on /etc (bad) or modify the policy of the other apps that may access the file to grant them the new context. Lather, rinse, and repeat until you've made a hash of the policy source (and the admin rips out his last chunk of hair).

        Then, now that you've hacked away and sliced and diced enough to grant everything just what it needs and then you do yum update. I swear, you can actually HEAR satan laughing maniacally below as you have to either abort the security update (and be insecure), turn off MAC (and be insecure) or accept that half your system will be broken now (I suppose an app that won't even run IS secure, but now the ADMIN feels insecure).

        what's needed is a policy.d directory. Each app is allowed to drop one file there that will be evaluated in isolation from whatever else is there to grant that particular app what it needs without having to understand the rest of the policy (perhaps modified locally anyway). The directory is there, but there's more than one and the files there have to understand the others and the global policy to avoid problems (like preventing the policy from compiling at all).

        Most places simply do not wish to pay for the amount of admin time required to make all of that work. In many cases, they're well justified in that, the data on the systems just isn't worth that much.

        When it is used, a common pattern is to run the app and then mindlessly add permisssions for whatever was denied until it finally works. The natural result is an overly permissive policy. All the disadvantages to using AppArmour automation plus granting entirely unnecessary access to any files related to the files needed.

        My post sounds almost entirely negative, but that would be unfair. In the environment SELinux was developed for, where leaked information can be a real disaster, it makes perfect sense to invest the administrative effort that is required. For the rest of us, it got the kernel code moving in the right direction for MAC and MLS. That makes follow on schemes better suited to the rest of us more likely to happen.

    • Re: (Score:3, Interesting)

      by Score Whore ( 32328 )
      Forget the pain in the ass nature of the kit. Consider the legality of it. The NSA cannot legally own copyright. Anything they produce is in the public domain. Therefore they cannot legally develop code that is under any license.
      • Forget the pain in the ass nature of the kit. Consider the legality of it. The NSA cannot legally own copyright. Anything they produce is in the public domain. Therefore they cannot legally develop code that is under any license.

        They can let contractors own it - happens all the time as a form of corporate socialism. They can also release to the public domain and let it be incorporated into the kernel - the GPL is compatible with the public domain. I really don't know what the NSA has done in this case, but licenses do not have to be an impediment here.

        • Re: (Score:3, Interesting)

          by Score Whore ( 32328 )

          They can let contractors own it - happens all the time as a form of corporate socialism.

          No they can't. They can contract with a contractor to develop a piece of code, but the government cannot develop something and then give it to a corporation. If government employees are building it, it's public domain. That's the nature of US law.

          They can also release to the public domain and let it be incorporated into the kernel - the GPL is compatible with the public domain.

          Your statement is fallacious because the co

          • No they can't. They can contract with a contractor to develop a piece of code, but the government cannot develop something and then give it to a corporation. If government employees are building it, it's public domain. That's the nature of US law.

            You presume that the employees are not employees of a contractor who have been emplaced at the government agency.

            There is nothing to be done to release it into the public domain as it's already there. The legal problem comes from the fact that it is a derivative of a GPLed program.

            I think you will find that a set of is not a derivative work [digital-law-online.info] because it does not contain the original work.

          • OK, so the NSA creates software, and that software is public domain. That means I can take it and incorporate it into a GPL project. The original code is still in the public domain.
    • by Arethan ( 223197 )
      I would have to agree. Having configured both SELinux and AppArmor to their desired effect, AppArmor is definitely the easier and faster of the two to get configured correctly. I'm much more likely to go through the effort to get AppArmor correctly configured, than piss around with SELinux for hours.

      SELinux may have more bells and whistles, but when you simply turn if off because it's a pain in the ass it doesn't really make your system any more secure.
    • by John Whitley ( 6067 ) on Sunday May 11, 2008 @03:44PM (#23371362) Homepage
      This was also why a lot of folks prefer the competing grsecurity system [grsecurity.net]. First listed among its features (and this has been available in grsec for years):

      An intelligent and robust Role-Based Access Control (RBAC) system that can generate least privilege policies for your entire system with no configuration
      grsec has a lot of other great features; see the link above for details. IMO, it's somewhat unfortunate that grsec has remained a separate patchset for the Linux kernel. Unusable security is useless security; I'm glad to see some catch-up on the SELinux front.

      Anyone out there who's used both grsec and SELinux + AppArmour want to favor us with a comparison?
    • by Tracy Reed ( 3563 ) <treed.ultraviolet@org> on Sunday May 11, 2008 @07:08PM (#23372816) Homepage
      I have been deployed around 30 CentOS 5 boxes over the last 6 months. I used to turn SE Linux off when it was expedient. Not anymore. I educated myself about how it works and a few basic commands. This:

      audit2allow -a -m local

      checkmodule -M -m -o local.m

      semodule_package -o local.pp -m local.mod

      semodule -i ./local.pp

      sequence of commands plus togglesebool has so far accomplished everything I have ever needed. I don't run any hand-written custom policy. And we have web servers, dns, mysql, web dev, and all kinds of other stuff.

      It sure is easier than setting up a bunch of iptables commands although I see it as analogous. I rarely hear people talk about what a pain iptables is (and it surely is a pain). I think learning SE Linux was even easier.

      I really look forward to more policy being applied to the desktop applications. That work is already well underway thanks to Dan Walsh over at RedHat who has already made a lot of progress in this area:

      http://danwalsh.livejournal.com/15700.html [livejournal.com]
      http://danwalsh.livejournal.com/18578.html [livejournal.com]
      http://danwalsh.livejournal.com/13376.html [livejournal.com]

      It is work like this that leads me to believe that Linux is not nearly so likely to become like Windows should it ever achieve a critical mass of desktop users. Security problems on the massive scale of some other operating systems are not inevitable. That is nice to know.

      Also, I will be doing a presentation on SE Linux at the Kernel Panic Linux Users Group:

      http://www.kernel-panic.org/meetings/general/08-07-10-general-meeting [kernel-panic.org]

      on July 10th, 2008. If you are in San Diego please stop by. It's a fun crowd and the after-meeting meeting at Denny's is always lively.
  • wrong (Score:3, Informative)

    by larry bagina ( 561269 ) on Sunday May 11, 2008 @11:19AM (#23369624) Journal
    SELinux adds both MAC and RBAC to the GNU/Linux operating system.

    No it doesn't. SELinux adds both MAC and RBAC to the Linux kernel.

    • SELinux has a userspace component, so it adds to both the "Linux kernel" AND the "GNU/Linux operating system".
      • by schon ( 31600 )
        Funny, I didn't know SELinux user-space utilites were part of the GNU project.

        Someone might want to tell the folks who maintain savannah.gnu.org, because there's no mention of it anywhere on their site.
        • Funny, I didn't know SELinux user-space utilites were part of the GNU project.

          It doesn't have to be owned by GNU to modify the GNU operating system. Next you'll tell me that the userspace component of a Windows driver isn't really a Windows program unless it's owned by Microsoft.

          The Unix-like OS that features the Linux kernel built by the GNU compiler running hundreds of GNU programs (via the GNU dynamic linker) that all communicate with the kernel through GNU libc is GNU/Linux. When the majority of Slack
  • This is timely, if nothing else. I've spent the last working day wrestling with what turned out to be SELinux, while trying to write a postfix filter. The way these work is postfix gives emails as command line options and STDIO, and the software (usually) connects to SMTP on an alternative port to move the email on. Except with SELinux running (which is installed by default in some distros), it fails. Silently. Please, take it away!
    • by HeroreV ( 869368 ) on Sunday May 11, 2008 @12:14PM (#23369956) Homepage
      Why not just fix the silent failure? I don't understand this mentality of "There's a bug in the system! Scrap the whole thing!"
    • by Znork ( 31774 )
      Make a note to make certain setroubleshoot or similar utility is always installed (on RH and derivatives it is, IIRC). That would have given you nice log output and instructions on how to resolve the problem.

      Silently.

      Yah, used to annoy the hell out of me. It's probably leaving a message in some audit log, but that isn't exactly friendly.

      With the appropriate daemons and utilities installed you should get a nice syslog message (or even a blinkety desktop icon if it's on your local machine). Then it's basicall
  • I guess I have never understood the fundamental difference; from TFS...

    The concept of a role differs from that of a traditional group in that a group represents one or more users. A role can represent multiple users, but it also represents the permissions that a set of users can perform.

    So a role is a group with permissions applied? WTF is the point of a group with no permissions applied?

    Now I understand you can have different kinds of groups: email/distro, file access, memory access, execute, etc. But even if you use one group to give all of these, that doesn't really make it different that a group with permissions.

    Is it all PHB/Marketing BS or am I missing something?

    • by init100 ( 915886 )

      The difference is that a traditional group can change the permissions of files that it owns, but with SELinux roles, the permissions can only be changed by the policy administrator. This is actually a primary distinction between DAC security and MAC security.

    • Is it all PHB/Marketing BS or am I missing something?
      Both :)

      The article should educate you a lot more than the summary does. Role-based-access controls tasks, whereas group-based-access controls resource access. SELinux doesn't supplant groups, it augments them.

      However, as usual, TFS is mostly PHP/Mareting BS aimed to get you to read the article and/or post in the comment thread.
  • by Ang31us ( 1132361 ) on Sunday May 11, 2008 @12:06PM (#23369922) Homepage
    Use SELinux commands like "restorecon" and "chcon" to fix SELinux context issues. Also, there is a GUI tool called "system-config-selinux" if you find that kind of stuff easier. If all else fails, use "setenforce" to put SELinux into WARN mode and look at the logs for clues about what is wrong.
  • by mattpalmer1086 ( 707360 ) on Sunday May 11, 2008 @12:10PM (#23369936)
    The definitions used by the article for discretionary, mandatory and role-based access control are a bit confused. They mix up the type of control with mechanisms commonly used to implement them. To be fair, there are no standard definitions of them - or at least, there's more than one "standard" definition. However, having just completed a dissertation in which I attempted to define those things, allow me to offer them here.

    Discretionary - a user has discretion to decide who has access to what. A common form of discretionary control is access control lists (ACLs), but capabilities are also discretionary. A big problem with discretionary control is the amount of work the user has to do to grant and revoke permissions to everything. This often leads to systems configured with too much permission - the opposite of principle of least privilege.

    Mandatory - the system mandates who has access to what by enforcing a policy (a user may set the policy, but can't grant access outside of that policy). Mandatory systems can require less work to administer day-to-day, as authorisation has been automated. But its often a lot of work to set good policies and are obviously less capable of dealing with things that fall outside of normal working practices. Common forms of mandatory control include label based systems like Bell-LaPadula or Biba (e.g. Top Secret: nuclear;projectX) and protection rings in CPUs.

    Role-based (RBAC)- the permissions of a user are taken from their role or roles. Lots of people ask why this isn't the same as using groups and access control lists. You can implement bits of RBAC using groups and ACLs, but full RBAC is more abstract than this, and explicitly allows for greater control - like separation of duties. The current "standard" is the NIST RBAC definition http://csrc.nist.gov/groups/SNS/rbac/ [nist.gov])

    Note that RBAC can be mandatory or discretionary - it doesn't say how the permissions are allocated to the roles, just how the user gets those permissions through the roles.
    • Role-based (RBAC)- the permissions of a user are taken from their role or roles. Lots of people ask why this isn't the same as using groups and access control lists. You can implement bits of RBAC using groups and ACLs, but full RBAC is more abstract than this, and explicitly allows for greater control - like separation of duties.

      Couldn't you accomplish separation of duties with groups (by using different groups for different duties) and/or setting up permissions in a less sweeping way in sudoers (not just always using "fubar ALL=(ALL) ALL")? I freely admit I know just enough to be dangerous; but sometimes I wonder if the problem is really just the way user/group permissions have traditionally been used in Linux/Unix.

      • You can arbitrarily approximate bits of RBAC using ACLs and groups, to different degrees in different systems. I'm not expert enough with using sudo to comment on your proposal, but as far as I'm aware, no ACL based system allows the user to pick which groups will be active during their session, nor does it allow the selection of groups to be controlled (e.g. if you pick group A, you can't have group B at the same time).

  • And I am referring to server environments where you aren't constant adding removing programs. If you think SELinux is a pain in the ass to use for any software that comes packaged for the distro you're using, either there is a problem with the package itself, or there is some strange thing wrong. If we were talking about SELinux in FC2 I would agree, but at F8 , EL5 level, there is really not excuse. The devs even made a tool which tells you exactly how ti fix issues that cause alerts|blocks.
    • by init100 ( 915886 )

      The problem is that people treat their systems like SELinux wasn't there, e.g. by moving stuff around without checking that the proper SELinux contexts are applied to the new location. Then when it doesn't work, they blame SELinux for not being able to read their minds.

  • If you have a program that responds to socket requests but doesn't need to access the file system, then that program should be able to listen on a given socket but not have access to the file system. ... This type of control is called mandatory access control (MAC).

    Am I mistaken, or does this have nothing to do with Mandatory Access Control? I was under the impressions that MAC (as opposed to DAC) was based on how the policy is implemented. In MAC the policy is defined by the administrator, whereas in DAC, the policy is defined by the users. The example seems like a policy is not an access control method.

    Perhaps the correct way to solve this misconception would be to find some better acronyms/names...

  • Without reading the article in any detail and researching things - this sounds a lot like what the .NET CAS (Code Access Security)features do, and have been doing so for around 6-7 years now.

    It is quite easy so configure a set of operations that I want an executable to be able to do, or not to do.

    I suppose I will get flamed and modded down for mentioning this :)

Marvelous! The super-user's going to boot me! What a finely tuned response to the situation!

Working...