| |||||||||||||
Linux security non-modules and AppArmorLinux security non-modules and AppArmorPosted Jun 28, 2007 15:40 UTC (Thu) by jamesm (guest, #2273)In reply to: Linux security non-modules and AppArmor by grandinj Parent article: Linux security non-modules and AppArmor
You're simply not understanding the essence of the discussion.
It's about architecture.
(Log in to post comments)
Linux security non-modules and AppArmor Posted Jun 28, 2007 16:16 UTC (Thu) by nix (subscriber, #2304) [Link] But people --- a lot of people, in real-world insecure environments --- are *turning SELinux off* and *running with no LSM at all* because it's simply too damn hard to understand a useful non-minimal SELinux configuration. (I have given up asking ordinary systems administrators to diagnose problems in SELinux configurations when SELinux gets in the way of something they're trying to do: you might as well ask them to fix kernel bugs on their own. They just turn it off, every time.)
Useful AppArmor configurations are very much smaller and easier to comprehend without having to do the sort of vast whole-system data flow analyses you're so fond of (and which nobody on the coalface has the time or inclination to do). Yes, maybe AppArmor *is* less secure than SELinux, but it's a hell of a lot more secure than *nothing*.
Linux security non-modules and AppArmor Posted Jun 28, 2007 16:38 UTC (Thu) by jamesm (guest, #2273) [Link] What you see deployed in Fedora/RHEL etc. is simply one possible combination of models and policies implemented using the SELinux framework.
You can make SELinux as "simple" as AppArmor by devising a simpler policy.
Linux security non-modules and AppArmor Posted Jun 28, 2007 16:50 UTC (Thu) by flewellyn (subscriber, #5047) [Link] It is true, though, that SELinux is kind of hard to use. Some higher-level policy-editing tools would be really helpful, I think.
Alternatively, since SELinux is an architecture, perhaps some of the policies built on it could be flexible abstractions themselves, so that they would define a simpler "language" for defining what the users want to do. Sort of analogous to what glibc does with abstracting away kernel interfaces.
Linux security non-modules and AppArmor Posted Jun 28, 2007 21:06 UTC (Thu) by smoogen (subscriber, #97) [Link] There are various higher level policy editing tools... they are just not well known. One of the issues comes down to what people want versus what they might need. People want the ability to not think about security because security is sold to them as being hard work, etc. This is why they will pay thousands of dollars for security systems that might only check to see if a door is open. Or they will pay for bars on their house windows, but then cant get out in a fire. Heck I have had to fix problems with several people who bought a small magnet that sits on top of their monitor that keeps out bad-guys. Everything else was tooo complicated.
My two problems with either of the solutions is marketing. Selinux people have been very good about reminding people that you need to think about things before you use them. Sometimes they are too good, and you feel that grandpa's old bomb-shelter is almost safe enough for your computers.
And too many of the AppArmour fan-boys will tell you that you don't need to think.. just install it and you will never have a problem.
At which point the religious wars about who is being the bigger idiot start up.
Linux security non-modules and AppArmor Posted Jun 28, 2007 22:19 UTC (Thu) by flewellyn (subscriber, #5047) [Link] True enough. What I'm thinking of is some kind of higher-level policy which (for instance) organizes programs and files into groups. Then you add the group tag to a user, and that user has access (notwithstanding any DAC restrictions) to that set of programs and files. Somewhat akin to how traditional UNIX groups are used, except with MAC enforcement.
Or am I being silly?
Linux security non-modules and AppArmor Posted Jun 29, 2007 7:50 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link] yes, some people don't know what they are talking about on all sodes of any topic.
however there are many people who do make a living in security who do see value in AppArmor, but you just dismiss them as not thinking things through or not understanding security.
you are trying to define security == SELinux
by your definition, anyone who proposes anything else just doesn't know what they are talking about.
there are applications where you really want the security context to follow the data file the way labels do in SELinux (think of a file containing your credit card number, you don't want the security on it to change just becouse you renamed it)
however in other cases all that really matters is what you would access by a particular name. (for example, the contents of what used to be called /etc/resolv.conf is of no value, all that matters is the current contents)
useing either approach to address the pther type of problem will only cause grief. SELinux was born in the NSA where they primarily deal with securing specific data, no matter where it moves. and there labeling data is the natural and best answer.
AppArmor approaches the security from the opposite direction. instead of labeling all the data and then defining what can access what it instead takes the approach of useing a 'label' that is already on the system, the pathname you use to access the file. It then lets you set rules about which of these labels a program can access.
another way of looking at AppArmor is that instead of being data-centric (identify the data you care about and list all the programs that access it) it's process-centric (identify the programs you care about and list all the data it can access)
SELinux is better if you are trying to defend a system against hostile local users. but since re-labeling data is extremely expensive you need to do a lot of analysis first.
Since AppArmor uses labels that already exist on the system, makeing radical changes to how any program can access any data doesn't require re-labeling any of the data (which can have secondary effects on policies for other programs that access the data), all you need to do is change the rules related to the program
There are other technical trade-offs involved in the implementation.
for AppArmor the hard thing (besides getting into the kernel) is determining the path for the thing being accessed.
SELinux has different problems
the need to figure out the path for AppAromor on one side vs the issues in figuring out what label a new file should have in SELinux
Linux security non-modules and AppArmor Posted Jun 29, 2007 15:06 UTC (Fri) by farnz (guest, #17727) [Link] AppArmor faces a much bigger problem; you've just said that you don't want a broken application to have unconstrained access to /etc/resolv.conf.'ln /etc/resolv.conf /tmp/mytempfile && echo broken >> /tmp/mytempfile'? Bear in mind that the interesting applications to confine run as root for part of their lifecycle, so that you need your confinement solution to confine root, too.
The basic issue with pathname based-security is the ease of accidentally breaking it. Most real-world programs that you want to secure (Apache, Mozilla, mutt) either have log files, or create temporary files, or both. Making it impossible to create hard links breaks expected UNIX functionality, so the reality is that unless you take an immense amount of care in writing policy, AppArmor ends up being security theatre, and easy to bypass.
Linux security non-modules and AppArmor Posted Jun 29, 2007 20:54 UTC (Fri) by nix (subscriber, #2304) [Link] OK, I'm missing something here. Mozilla, Apache, and mutt, your ownexamples, run as root for part of their lifecycle?!
(The very *idea* of a suid root Mozilla gives me collywobbles.)
Linux security non-modules and AppArmor Posted Jul 1, 2007 9:32 UTC (Sun) by njs (guest, #40338) [Link] Well, Apache on port 80 does...
Linux security non-modules and AppArmor Posted Jul 2, 2007 8:07 UTC (Mon) by farnz (guest, #17727) [Link] My Apache runs on port 80, which can only be bound by root. My SMTP server runs on port 25, which can only be bound by root (not in the list of examples, but I did rather assume that you'd apply some intelligence). My SSH daemon runs as root briefly (setting up port 22, and changing user to the user who's logging in).Indeed, all the long-running services on my boxes must run as root for part of their lifetime, just to bind their well-known ports for listening. Mozilla and mutt obviously don't run as root at all, but they're not necessarily that interesting to confine (e.g. on a server).
Linux security non-modules and AppArmor Posted Jun 30, 2007 6:34 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link] where did you get the idea that AppArmor can't constrain a process running as root?
one of the things that AppArmor does is limit what links a constrained process can create, exactly to prevent the type of loophole that you are trying to make (IIRC they do something along the lines of 'you can't make a link to a file that you can't write to' or something along those lines)
AppArmor is limiting what the httpd process can do, not what the apache user can do, it doesn't matter what userid the process is running as.
Linux security non-modules and AppArmor Posted Jun 30, 2007 16:33 UTC (Sat) by drag (subscriber, #31333) [Link] Well there is a fundamental flaw in pathnames that he is trying to point out, abiet unsuccessfully.
You see that is were the problem is. Absolute pathnames are not realy all that absolute. It's possible to have multiple names for the same files. It's possible to have weird directory setups were the same stuff appears multiple times in different directories and different paths.
Plus when your dealing with kernel-level stuff pathnames are pretty much immaterial because the kernel deals with lower-level stuff then all that. I don't understand all of it myself, but your dealing with situations were the kernel has to continiously loop back into userspace to determine what Apparmor is talking about.
So AppArmor is making things _deceptively_ simple instead of actually making it simple. It's just hiding complexity and control from the end user while setting you up for nasty security holes in corner cases. To actually effectively use it you have to actually understand everything that is going on, because it is easier to set rules does not make it actually simplier to effectively impliment versus SELinux.
What he is saying is:
I don't want to get into a big arguement about it. I don't know if he is right. If you have technical reasons why he is wrong then actually I would love to hear it because it would make it easier for myself to understand what is going on.
But you saying "AppArmor is easy" and that's why some people need it doesn't realy have much to do with what he is talking about because (I suppose) SELinux can be made "easy" in that way also.
It's like that Fire-proof door vs regular Door vs gaping hole thing that came up a few posts back.
If your going to have a door, then why not make it a good and effective door? There is no reason why a effective firedoor door can't be as user-friendly as a less effective door. At least in software-land.
Linux security non-modules and AppArmor Posted Jul 2, 2007 8:52 UTC (Mon) by farnz (guest, #17727) [Link] You've read a bit too much into what I'm saying. All I'm trying to point out is that the use of pathnames as your stable identifiers is rather weak if you're not thinking things through; this becomes especially true if a program uses hard links in normal operation. If you're thinking things through in enough detail to catch all the corner cases, you're also thinking things through in enough detail to write a label-based policy that works.It's all too easy to write a policy like "Read /etc/resolv.conf, read/write/modify/hardlink in /tmp" without thinking about the details of what that allows; worse, the exact behaviour of that security policy depends on system partitioning. On my home machines, where /tmp is in its own partition, that policy is safe. On my work machines, where I have a single large /, that policy is dangerous. Note that it's the use of pathnames as stable identifiers in policy that concerns me, not the rest of the AppArmor kernel-side. A simpler policy format using file labels wouldn't worry me at all.
Linux security non-modules and AppArmor Posted Jul 4, 2007 21:53 UTC (Wed) by skybrian (subscriber, #365) [Link] It seems like this could be easily solved by disallowing the creation of additional hard links for protected files? If a file is only in one place, mapping inodes to absolute paths might be easier too.
Linux security non-modules and AppArmor Posted Jul 5, 2007 8:48 UTC (Thu) by farnz (guest, #17727) [Link] You've just changed the problem round. What do you mean by protected files?If you mean files that AppArmor policy covers, then you're implying that you're banning hard links entirely, as in a full deployment of AppArmor, all files are covered by policy. If you mean files that this program cannot access under the current AppArmor policy, you now have to audit all pairs of programs, and ensure that there is no case where one program which has legitimate access to a sensitive file (e.g. dhcpd in the case of /etc/resolv.conf) can create a hardlink to that file in an area where another process (e.g. an Apache with a security flaw) can create a hardlink to it. Putting that into a concrete example:
Granted, I'd have had an exploit with or without AppArmor in this case (without AppArmor, Apache could have just overwritten /tmp/dhcpdXXXXresolv or /etc/resolv.conf), but this is exactly the sort of issue a system like AppArmor should protect against; note that I've only posited one buggy program (Apache), and a policy that should confine that process to being unable to edit /etc/resolv.conf, and yet my hypothetical bad guy can still break things. In contrast, with a label-based system, I'd have a label network-config-file, and all files created by dhcpd would get that label by default. Even though I've not noticed dhcpd's actions in /tmp, Apache can't get access, as it's not allowed to write to network-config-files. Oh, and again note that the exploitability of this bug depends on partitioning. If I wrote this policy on my home machine (/tmp on a separate partition), I'd not see this flaw at all; if I used it at work (one big / partition), I'd be broken. There's also no easy way to audit a system setup, and confirm that I've not broken the policy; with a label-based system, I just have to check that all filesystems support labelling. With this pathname based system, I have to look at whether my partitioning layout matches the partitioning on the policy developer's system, and whether the differences open holes in policy.
Linux security non-modules and AppArmor Posted Jul 5, 2007 16:15 UTC (Thu) by skybrian (subscriber, #365) [Link] If policy is based on paths, then it seems like hard links between any two paths that have different security policies has to be disallowed (for example, between /etc and /tmp). Otherwise you've got files that appear under more than one security level. Any kind of copy between files at paths with different security levels untaints the data.
A taint-based system does seem more appealing if it could be made to work. It occurs to me that we have something close to that already, except that the security label is the owner and group of the file. The issues with setting the label for new files are similar to deciding what the owner, group, and umask should be for a new file. Maybe this would be more popular if security labels were something familiar? A special kind of group?
Linux security non-modules and AppArmor Posted Jul 6, 2007 8:29 UTC (Fri) by farnz (guest, #17727) [Link] You're still facing two problems with hard links:
Linux security non-modules and AppArmor Posted Jun 29, 2007 16:18 UTC (Fri) by smoogen (subscriber, #97) [Link] Thanks for the reasoned reply. I do not believe that security == SELinux, but I do have to worry about hostile local users... very very much so. So in that case I usually have to do all the work that is going on with an SELinux system.
|
|||||||||||||