Linux security non-modules and AppArmor [LWN.net]

Long-time LWN readers will know that the Linux security module (LSM) API is controversial at best. To many, it has failed in its purpose, which is enabling the development of competing approaches to hardened Linux system; the only significant in-tree security module remains SELinux. Meanwhile, the LSM interface is easily abused; since it allows the insertion of hooks into almost any system operation of interest, it can be used by other modules to provide non-security functionality. The LSM symbols are mostly exported GPL-only, but it is still possible for binary-only modules to abuse the LSM operations - and, apparently, some have done so.

SELinux hacker James Morris has been pondering this issue recently; he has also noticed that the in-tree security modules (SELinux and the small module implementing capabilities) cannot be unloaded. So, he asked, why implement a modular interface at all? He has posted a patch which turns LSM into a static API with no exported symbols. With this patch applied, any needed security "modules" must be built into the kernel; there is no longer any way to add them at run time.

There have been a few complaints, but, from your editor's point of view, it does not seem like anybody has come up with a compelling reason why it must be possible to unload security modules. Instead, it has been pointed out that maintaining a coherent security state in the presence of unloadable modules is nearly impossible. So this patch would appear to have reasonably good chances of being applied. The only question, perhaps, is whether the developers feel the need to provide an extended warning period for developers and users of out-of-tree security modules.

One such module is AppArmor - the GPL-licensed security mechanism distributed by Novell. AppArmor has remained out of the tree for a long time while its developers have tried to address the various comments which have been posted over the years. A new AppArmor patch has been posted; many things have been fixed, but one of the core points remains: AppArmor still uses a pathname-based mechanism for its policy enforcement. This approach sits poorly with developers - especially those in the SELinux camp - who think that pathnames are an inherently insecure method. In their view, the only truly secure way to control access to objects is to put labels on the objects themselves.

It seemed that this dispute had been resolved at the 2006 kernel summit, where it was determined that the use of pathnames was not enough to keep AppArmor out of the kernel. That has not stopped people from complaining, though, and those complaints redoubled when another pathname-based approach (TOMOYO Linux) was posted recently. If AppArmor does get into the mainline, it will have to be over the objections of developers who feel that is providing false security to its users.

Andrew Morton appears to want to resolve this issue and get it off the mailing lists; he sees two alternatives:

a) set aside the technical issues and grudgingly merge this stuff as a service to Suse and to their users (both of which entities are very important to us) and leave it all as an object lesson in how-not-to-develop-kernel-features. [...]

b) leave it out and require that Suse wear the permanent cost and quality impact of maintaining it out-of-tree. It will still be an object lesson in how-not-to-develop-kernel-features.

It seems that Andrew would rather not be in the position of delivering object lessons on how not to develop kernel code by whatever means; he concludes with this request:

Sigh. Please don't put us in this position again. Get stuff upstream before shipping it to customers, OK? It ain't rocket science.

At the 2006 summit, Linus took a clear position that the use of pathnames for security policies seemed reasonable to him. Given that, along with the fact that AppArmor is being widely distributed, and it seems that, sooner or later, this module should find a home in the mainline - even if it is no longer in modular form.

Index entries for this article
Kernel	AppArmor
Kernel	Security/Security modules
Security	AppArmor
Security	Linux Security Modules (LSM)

to post comments

Linux security non-modules and AppArmor

Posted Jun 28, 2007 4:54 UTC (Thu) by jamesm (guest, #2273) [Link] (35 responses)

There's more to this than pathnames. Unfortunately, an important issue that has been lost in discussions is that of security architecture.

SELinux is a security framework. It's not simply one particular security model, but an architecture for composing different types of security models in a coherent manner.

It is analogous to the VFS or the networking stack, rather than a specific filesystem or network protocol.

One of the outstanding issues with AppArmor being merged upstream is how it relates to the kernel's security architecture. The idea with SELinux, from the start, has to been to extend the old Unix DAC model with an extensible framework, to allow Linux to accomodate a wider variety of security models (such as RBAC and TE).

One key concept with this framework is that it is "policy flexible". That is, it implements a clean separation of mechanism and policy. So in addition to supporting multiple security models, each of these can be deployed in a manner suiting a wide range of requirements (including notions of "good enough" security which allow simpler policy).

Another key concept is re-use of mechanisms. The policy, auditing, labeling and enforcing frameworks are cleanly abstracted so that different types of security models can be integrated into the overall framework. Policy for the entire system can be designed and analyzed in a complete and coherent manner, while a consistent set of APIs and abstractions are provided to applications, and a common set of libraries and tools are used for development and management.

Note that the literature shows that composition of different security models is a potentially dangerous area, and that subtle and entirely unexpected security issues can be introduced without appropriate overall control. LSM cannot thus be thought of a scheme for security module compostion, as it lacks any common infrastructure: it's just a large bunch of hooks littered throughout the kernel. OTOH, SELinux was actually designed to do this in a way that allows the resulting compound security policy to be fully analyzed. And by design, I mean the result of decades of advanced (NSA) research, with prototyping in several OSs followed by volumes of technical analysis. What we see with SELinux is simply the decsion to transfer the results of all of this work into a general purpose operating system, and the fact that it was done upstream in Linux should tell you something about the level of clue.

Anwyay, without going too deeply into the design, I hope I've now established the idea of SELinux as a security architecture and some aspects of its bona fides as an architecture.

The problem, the deep problem we face now is that as long as LSM remains, SELinux will remain as "just another" security module, and it will never be considered a first class component of the kernel. Kernel developers will forever have to deal with the weak semantics of LSM, without understanding what is supposed to be going on behind the hooks, and quite understandably, not bother thinking too deeply about extended security. SELinux provides much stronger semantics as an in-kernel API, and can provide a consistent conceptual model for general kernel developers in the same way that the existing DAC code does now. Related is the user experience, where again, application developers, sysadmins and other technical folk will generally see extended security as an optional pluggable idea with weak semantics, that they will continue not to buy into because of this.

Linux needs to provide clear semantics and conceptual models; be it security, networking, filesystems, drivers or pretty much anything where different types of models can be deployed.

If we continue the analogy of the network stack: imagine that a decision had been made years ago to make the whole stack pluggable. What we would have now, I believe, the network kitchen-sink from hell, with no underlying design or consistency. We'd likely have merged every bad idea to make it into a thesis or marketing brochure: sysv streams, TOE, hare-brained and half-assed research projects, and enough snake-oil to power the world for a decade. And who would bother maintaining it all?

It simply would not have been possible to develop systemic network improvements such as Netfilter, IPsec, advanced routing & traffic control, nor would there be a foundation for the performance work applied across the stack, or for genneral infrastructure improvements that people have been working on recently.

To put it another way, we would not have been able to evolve what is arguably the best network stack ever. Recall Van Jacobson's comments on it at LCA06: "The people who take care of the stack know what they're doing and do good work", "... Linux has the fastest and most complete stack of any OS". With the LSM approach, this is never going to be said for Linux's security core.

Further imagine how pluggable stacks would have played out at the distro level, and where it would leave the users in terms of compatabilty and consistency with Linux networking. It would also be unsupportable upstream:

"Routing doesn't work! I add the default route and everything stops."

"Uh, which network stack are you using, and is it even in the kernel?"

"I don't know :'-(" <- note, user crying

I think we're about to make this mistake with security: by not adopting SELinux as the security framework; by avoiding real architectural discussion; by allowing technical issues to be framed politically; and by not listening to people who know what they're talking about.

Linux security non-modules and AppArmor

Posted Jun 28, 2007 5:28 UTC (Thu) by dlang (guest, #313) [Link] (2 responses)

that's a good restatement of the SELinux pitch. A shorter version is that SELinux can do everything and nothing else is needed.

except that the SELinux framework cannot reasonably implement the AppArmor semantics since a simple rename could require the relabeling of thousands of files before the system works properly.

and no, I don't buy the answer from the SELinux camp of "well, don't do that then" as being reasonable

for the record I am not a current user of AA, however I definantly see it as being useful and would start useing it within a couple of months of it being included.

the arguments against keeping the LSM modular all assume a SELinux approach of tagging everything and worry about how to tag things on module insertion and what to do with the tags on module removal.

if you look at other possible modules the answers are much clearer.

for example, with App Armor when you unload the module everything is unconstrained. when you load a module all future accesses are checked (if the name of the program being run can only be found at execution time then it could only constrain programs executed after it's loaded, which could be an advantage under some conditions)

another LSM I ran across recently allowed you to limit network use by programs. it also seems like the load/unload events would be clear (or at least straightforward)

Linux security non-modules and AppArmor

Posted Jun 28, 2007 10:15 UTC (Thu) by mingo (subscriber, #31122) [Link] (1 responses)

Note that you did not actually answer to the essence of James' arguments.

it boils down to: the architecture of SELinux is there for a reason (and it is well documented), and the answer is not to ignore it and remove the "extra complexity" out of ignorance, but to understand the security issues behind them and provide an alternative solution (if you can).

You are in essence putting a chair into the fire-proof door to keep it open permanently, just because you find it inconvenient. Instead of designing an automatic fire-proof door that opens automatically when a human (with the right permission) approaches.

Linux security non-modules and AppArmor

Posted Jun 28, 2007 14:47 UTC (Thu) by jschrod (subscriber, #1646) [Link]

Maybe he doesn't need fire-proof doors all the time, but is also not satisfied with a hole in a wall -- sometimes a door itself would be sufficient.

Coming back from your analogy: Implementing "just a door" in SELinux is horrible work, and many users then take the hole in the wall instead, i.e., they shut it off. I see this daily at my customers' installations.

Decisions about security mechanisms are not black and white, like all other security decisions. They are a compromise between effort, risk, and asset value. Sometimes the big hammer SELinux is the tool to use, but there are other situations, too -- and not all of them demand the big hammer.

Linux security non-modules and AppArmor

Posted Jun 28, 2007 5:36 UTC (Thu) by arjan (subscriber, #36785) [Link] (2 responses)

While I don't automatically want to agree that SELinux is the One True Thing, I do agree that LSM was a mistake in hindsight.

LSM was created because the security folks (many of whom were thinking of doing binary only proprietary things) couldn't agree. LInus decreed basically "I don't want to care so make it go away behind some interface". It made security stuff the 5th wheel of the kernel, with little visibility towards a real design... especially with most LSM stuff out of tree it's just hard to see how things really fit together.

I'm sad to see that many of the original companies and groups that are the cause of the LSM debacle just never came forward. The only one who half came forward is AppArmor, and it's funny to see how that sort of gets posted once a year, just in time for the Kernel Summit to have another "don't remove LSM because we're still here" argument...

Path based security has issues, and the one that Johnathan missed is the one where AppArmor has to reconstruct a full pathname by going backwards up the tree. That is just a major problem (and that is not the part that was seen at the last kernel summit as "ok"; only the "look at filenames" part was).

Anyway today we have a set of random hooks that have relatively unclear semantics, of which all but one user are out of tree so we can't do a sweep to even check if they are the right interface.... and the hooks also add a performance cost due to the indirect function pointer calls. At least the proposed path is step 1 to getting rid of the indirect calls and just having a "CONFIG_SELINUX_ONLY" option which turns the calls into direct calls.... killing the not insignificant function pointer call overhead.

Linux security non-modules and AppArmor

Posted Jun 28, 2007 19:56 UTC (Thu) by i3839 (guest, #31386) [Link] (1 responses)

What about replacing those indirect function pointer calls with that strange new "alernative" thing, patching the right call in when needed?

Sure, it's ugly, but if it's a real performance problem, then why not? Would mean that having LSM enabled without running any security module wouldn't cost anything either. Of course it isn't needed when LSM goes away, just an idea for when it isn't.

Linux security non-modules and AppArmor

Posted Jun 29, 2007 5:00 UTC (Fri) by arjan (subscriber, #36785) [Link]

yes; the proposed patch is a good step in making that actually practical...

Linux security non-modules and AppArmor

Posted Jun 28, 2007 8:47 UTC (Thu) by ljt (guest, #33337) [Link] (1 responses)

I agree fully: selinux must be included in the kernel the same way memory management, network or vfs are.

I think though that selinux would gain a BIG user mindshare by becoming less opaque: Common mortal *cannot* know which constraints a process is under.
There is tool to see the label in files, but there is no tools (that I am aware of) to see in which context a process is under and what it is allowed to do.
Take the legacy DAC model: ps gives you the uid/gid, this is all you know to match the ressources it can manipulate.

Make no mistake: inspecting .mod, .te, .pp objects is to selinux what forensic is to live debugging. We *must* have _live_ and _convenient_ tools to:
-See process contexts and the relvant rules it is under
-Apply or remove type enforcement rules the same way chcon works (think pscon)
-Provoque transitions between process contexts while running

It is currently a PITA to admin the thing in a mission critical environment

Linux security non-modules and AppArmor

Posted Jun 28, 2007 11:48 UTC (Thu) by jamesm (guest, #2273) [Link]

Thanks for the feedback. You can see what context a process is running under with -Z (this works for many tools, even things like netstat), but you're right that we need to do a lot more work on management. Likely we'll be able to make use of the exported runtime policy idea you mentioned recently.

Linux security non-modules and AppArmor

Posted Jun 28, 2007 11:42 UTC (Thu) by grandinj (guest, #5057) [Link] (24 responses)

And the reply from the AppArmour guys would be that SELinux tries to be too many things to too many people.

You're effectively trying to win this debate by decree.

AppArmour may not be perfect, and it may not provide perfect protection, but it provides a valuable amount of extra protection for a fairly minimal amount of work, and it does so in a way that mere mortals find reasonably easy to work with.

It's a classic case of theory vs. practice. In theory, SELinux is the best choice, but in the Real World (tm), for the "invisible majority" of users, AppArmour is good enough.

Linux security non-modules and AppArmor

Posted Jun 28, 2007 11:59 UTC (Thu) by jamesm (guest, #2273) [Link] (23 responses)

This has been the problem all along. People refuse to listen to technical arguments.

Once again: you can implement an extremely wide range of policies in SELinux, including "good enough" schemes that trade correctness for simplicty.

This is called policy-flexibility.

You can also add different types of models, at the same time, and have them composed in a coherent manner using consistent kernel and user APIs.

Have a look at the SEEedit project for an AA-like scheme implemented with SELinux.

And before the pathname thing comes up again, please stop and think about what the actual _requirements_ of the user are, what the most appropriate way to model them are in the Linux kernel and what kind of abstraction would then be most appropriate for the user.

Remember, horse before cart.

Linux security non-modules and AppArmor

Posted Jun 28, 2007 13:14 UTC (Thu) by grandinj (guest, #5057) [Link] (22 responses)

That may well be so.

But if you're implementing a security scheme that aims to be "good enough", why would you drag in a project where

(a) your intentions are continually derided i.e. you are treated as a second-class citizen
(b) adds a HUGE chunk of extra complexity to a security project i.e. a project in which you really want to know how all the bits work.

The pathname thing appears to work. __You__ may not like it, but the thing is, it works - maybe not perfectly, and there sure are cases where it can be tripped up, but it does pretty well.

Remember, perfect is the enemy of good.

Linux security non-modules and AppArmor

Posted Jun 28, 2007 14:01 UTC (Thu) by flewellyn (subscriber, #5047) [Link] (20 responses)

In a security context, "appears to work" is extremely dangerous. If your security system appears to work, but in fact does not, it leads to a false sense of security, which is worse than no security at all.

Sure, AppArmor appears to work, but SELinux has been proven, through years of high-level research, to work. That's a critical difference.

Linux security non-modules and AppArmor

Posted Jun 28, 2007 15:14 UTC (Thu) by grandinj (guest, #5057) [Link] (19 responses)

What we're dealing with here are straightforward engineering trade-offs.

A highly-complex but very complete system
vs.
A relatively simple but not complete system.

This is why the LSM is a good idea - so that end-users get to make the choice that works for them.

Linux security non-modules and AppArmor

Posted Jun 28, 2007 15:40 UTC (Thu) by jamesm (guest, #2273) [Link] (18 responses)

You're simply not understanding the essence of the discussion.

It's about architecture.

Linux security non-modules and AppArmor

Posted Jun 28, 2007 16:16 UTC (Thu) by nix (subscriber, #2304) [Link] (17 responses)

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] (16 responses)

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] (15 responses)

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] (14 responses)

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 (guest, #313) [Link] (12 responses)

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
what to label new files that are created
how to configure a policy to grant access to a new file automaticaly
the need for special tools when manipulating data to change the label

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 (subscriber, #17727) [Link] (10 responses)

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. that application also needs to create files (e.g. log files, temporary files etc), what stops it from doing something like '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] (2 responses)

OK, I'm missing something here. Mozilla, Apache, and mutt, your own
examples, 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 (subscriber, #40338) [Link]

Well, Apache on port 80 does...

Linux security non-modules and AppArmor

Posted Jul 2, 2007 8:07 UTC (Mon) by farnz (subscriber, #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 (guest, #313) [Link] (2 responses)

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 (guest, #31333) [Link] (1 responses)

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:
* SELinux is a more realistic design based on the realities of how the software and machines work.
* SELinux can do everything AppArmor can do.
* AppArmor can't do everything that SELinux can do.
* It's very possible that SELinux can be made to be as 'simple' as AppArmor is, probably through the use of user-land programs to help set it up for admins.

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 (subscriber, #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 (guest, #365) [Link] (3 responses)

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 (subscriber, #17727) [Link] (2 responses)

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:

You create policy that prevents Apache from writing /etc/resolv.conf
You create policy that lets dhcpd write /etc/resolv.conf
dhcpd (for whatever reason) creates a new file /tmp/dhcpdXXXXresolv in the process of operation, and fills in the data that will become /etc/resolv.conf
Apache hardlinks to /tmp/dhcpdXXXXresolv, as the security flaw has been exploited
dhcpd moves /tmp/dhcpdXXXXresolv to /etc/resolv.conf

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 (guest, #365) [Link] (1 responses)

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 (subscriber, #17727) [Link]

You're still facing two problems with hard links:

I can create a hard link in /tmp to another file in /tmp, and then (assuming suitable partitioning), someone else can move the file or the hard link to /etc. The move creates a hard link from /tmp to /etc, so you'd have to ban use of rename(2) to atomically move files from one location to another.
Security policy is per-application; any path has multiple different security policies applying to it, depending on which application is accessing it. Working out the union of policies, and only allowing hard links if the union of policies is "safe" is a hard task.

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.

Linux security non-modules and AppArmor

Posted Jun 28, 2007 18:00 UTC (Thu) by vmole (guest, #111) [Link]

The pathname thing appears to work.

Using the return from malloc() without checking it appears to work, too. Most of the time, anyway. And checking every returned pointer for NULL is complicated and tedious.

Linux security non-modules and AppArmor

Posted Jun 28, 2007 16:34 UTC (Thu) by akumria (guest, #7773) [Link] (1 responses)

One key concept with this framework is that it is "policy flexible". That is, it implements a clean separation of mechanism and policy.

I actually think this is a big problem with SELinux. As far as I know — and I could be wrong but that's never stopped me before! — the kernel is fairly inflexible with that what the superuser uid must be (i.e. 0).

So, why shouldn't there be an "in-kernel" RBAC security policy, or an "in-kernel" TE (Type Enforcement) security policy implemented directly on-top of LSM.

Your recent patch to disallow unloading of security modules give rise to the question, to me anyway, as to why anyone would want to have RBAC and TE security policy implemented at the same time.

Thanks, Anand

Linux security non-modules and AppArmor

Posted Jun 28, 2007 18:53 UTC (Thu) by jamesm (guest, #2273) [Link]

Traditional DAC is based on an extremely simple binary notion, where euid==0 represents full privilege. The semantics of this are clear, and indeed, this policy may be hard-coded into the kernel.

Beyond DAC (which is definitely inadequate for today's computing environment), the models and their semantics become more complicated. With this complexity, it's important to maintain a separation of mechanism and policy (as a general principle, too), so that different sets of requirements can be met. The policy-flexible design in SELinux arose directly from unsatisfactory experiences with earlier MAC security schemes where policy was hard-coded into the mechanism. In particular, it's been extremely rare to see "trusted" Unix systems in anything other than very specialized situations such as handling classified information.

Policy-flexibility is one of the characteristics of SELinux which makes it suitable not only for these situations, but also for general purpose computing such as a web server or cell phone. This is with no code changes, just different policies loaded.

I'd suggest reading some SELinux docs for more detailed background on the design and its rationale.

e.g. http://www.nsa.gov/selinux/papers/ottawa01/index.html

(the introduction is very useful).