Pathname matching, transition table loading, profile loading and
manipulation.
Signed-off-by: John Johansen <jjohansen@suse.de>
Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
---
security/apparmor/match.c | 232 ++++++++++++
security/apparmor/match.h | 83 ++++
security/apparmor/module_interface.c | 643 +++++++++++++++++++++++++++++++++++
3 files changed, 958 insertions(+)
--- /dev/null
+++ b/security/apparmor/match.c
@@ -0,0 +1,232 @@
+/*
+ * Copyright (C) 2007 Novell/SUSE
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2 of the
+ * License.
+ *
+ * Regular expression transition table matching
+ */
+
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <linux/errno.h>
+#include "match.h"
+
+static struct table_header *unpack_table(void *blob, size_t bsize)
+{
+ struct table_header *table = NULL;
+ struct table_header th;
+ size_t tsize;
+
+ if (bsize < sizeof(struct table_header))
+ goto out;
+
+ th.td_id = be16_to_cpu(*(u16 *) (blob));
+ th.td_flags = be16_to_cpu(*(u16 *) (blob + 2));
+ th.td_lolen = be32_to_cpu(*(u32 *) (blob + 8));
+ blob += sizeof(struct table_header);
+
+ if (!(th.td_flags == YYTD_DATA16 || th.td_flags == YYTD_DATA32 ||
+ th.td_flags == YYTD_DATA8))
+ goto out;
+
+ tsize = table_size(th.td_lolen, th.td_flags);
+ if (bsize < tsize)
+ goto out;
+
+ table = kmalloc(tsize, GFP_KERNEL);
+ if (table) {
+ *table = th;
+ if (th.td_flags == YYTD_DATA8)
+ UNPACK_ARRAY(table->td_data, blob, th.td_lolen,
+ u8, byte_to_byte);
+ else if (th.td_flags == YYTD_DATA16)
+ UNPACK_ARRAY(table->td_data, blob, th.td_lolen,
+ u16, be16_to_cpu);
+ else
+ UNPACK_ARRAY(table->td_data, blob, th.td_lolen,
+ u32, be32_to_cpu);
+ }
+
+out:
+ return table;
+}
+
+int unpack_dfa(struct a...So we get small interpretter of state machines, and reason we need is is 'apparmor is misdesigned and works with paths when it should have worked with handles'. If you solve the 'new file problem', aa becomes subset of selinux.. And I'm pretty sure patch will be nicer than this. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -
I assume you mean labels instead of handles. AppArmor's design is around paths not labels, and independent of whether or not you like AppArmor, this design leads to a useful security model distinct from the SELinux security model (which is useful in its own ways). The differences between those models cannot be argued away, neither is a subset of the other, and neither is a misdesign. I would be thankful if you could You are quite mistaken. SELinux turns pathnames into labels when it initially labels all files (when a policy is rolled out), whereas AppArmor computes the "label" of each file when a file is opened. The two models start to diverge as soon as files are renamed: in SELinux, labels stick with the files. In AppArmor, "labels" stick with the names. So what you advocate for is a hybrid between the SELinux and the AppArmor model, not a superset. It could be that the SELinux folks will solve the issues they are having with new files using something better than restorecond in the future, perhaps even an in-kernel mechanism (although I somewhat doubt it). But then again, their basic model makes sense even without any live file relabeling, and so that's probably not very high up on the priority list. Andreas
I have a hard time distinguishing AppArmor's "model" from its implementation; every time we suggest that one might emulate much of AppArmor's functionality on SELinux (as in SEEdit), someone points to a specific characteristic of the AppArmor implementation that cannot be emulated in this manner. But is that implementation characteristic an actual requirement or just how it happens to have been done to date in AA? And I get the impression that even if we extended SELinux in certain ways to ease such emulation, the AA folks would never be satisfied because the implementation would still differ. Can we separate the desired functionality and actual requirements from the I'd argue a bit with that characterization, given that: - in the case of SELinux, the pathname is never used as a basis for decisions by the kernel, - under AA, each file may have an arbitrary set of "labels" or "policies" applied to it depending on what programs are accessing it and what names are being used to reference it - there is no system view of the subjects and objects and thus no way to identify the overall system policy for a given file. Live file relabeling (non-tranquility) tends to break one's ability to show anything about preservation of confidentiality or integrity (particularly in the absence of complete revocation support). On the new files issue, it wouldn't be difficult or even a real divergence from our existing model to introduce the component name (not a "full" pathname, but the last component) as an additional input to the decision for labeling new files (along with the existing use of the creating process' label, the parent directory label, and the kind of new file) at creation time, and that would reduce the need somewhat to modify some applications that create files of multiple security contexts in the same directory. That would further help the SEEdit folks in emulating AA on top of SELinux, but as before, I don't get the impression that the AA folks will ever be satisfied with su...
Indeed, the kernel component of SELinux only uses file labels for making file access decisions and not pathnames. But those labels were initially created by a trusted process (e.g. restorecon) based on pathnames, and this initial labeling is an essential part of the SELinux model. So in a sense, disregarding creation and relabeling of files, one could argue that SELinux makes decisions based on the pathnames that files had when they were labeled. In SELinux, labels are the only thing that distinguishes between files. So if at one point you find that you need to distinguish between files that share a label, you have to split the label and reclassify the files in addition to adjusting the policy. Again, the usual approach for reclassifying files will probably be pathname based. In contrast, AppArmor does not use labels, and the pathnames at the time of access distinguish between files. Since files do not have labels, no Look at it this way: under SELinux, the set of files that share a label forms an equivalence class -- they are all treated identically by the system's security policy. The rules in AppArmor profiles also define equivalence classes in the sense that they partition the filesystem namespace into sets of files that are treated identically, but this classification is not explicit -- the entire rule base contributes to the classification. This doesn't mean that there is not a global policy, just that the policy is modeled differently. The equivalence classes are not directly obvious from the AA profiles. Contrast this with SEEdit, which compiles AA-style rules into labels (and thus equivalence classes). The resulting SELinux policy is a static snapshot that cannot easily accommodate rule base changes, is more limited with respect to new files (which would likely be fixable), and behaves differently in complex ways with file renames. What's more, most likely the compiled policy will be anywhere from very hard to impossible to analyze, so you pre...
No, it really does mean that there is no global policy, and it goes beyond "not directly obvious" to "can not be determined" from the AA profiles. You can't compose the set of AA profiles and say anything useful, because they are written in terms of ambiguous and unstable identifiers. /a/b/c may refer to completely different objects in two different profiles, or to the same object as /d/e/f in the same or Just to clarify, you can change the allowed accesses from a given subject to a given object without relabeling, just by changing the policy allow rules; you only have to relabel the object in the case where you want to distinguish that object from another object with the same label for the same subject. I think the new file situation could be improved without any major change to the SELinux model, and am not opposed to leveraging the component name there, as previously noted. On the file rename case, I think we have it right - access rights shouldn't change automatically when a file is renamed, any more than DAC ownership Tranquility is important to correctness and understandability of policy; if labels (or pathnames in your case) can change at any time, then you have the problems of revocation of access (impractical to completely implement in Linux) and your effective policy now varies over time, so I'd agree that we shouldn't try to emulate AA as it is on SELinux. The question is more of whether we can meet the higher level functionality goals that make some people want to use AA via SELinux. That requires separating those goals from the implementation details of AA. -- Stephen Smalley National Security Agency -
Woah, that describes the userspace side of AA just fine, it means nothing when it comes to the in-kernel implementation. There is no reason that you can't implement the same functionality using some I am still not completely certian that we can not properly implement AA functionality using a SELinux backend solution. Yes, the current tools that try to implement this are still lacking, and maybe the kernel needs to change, but that is possible. I still want to see a definition of the AA "model" that we can then use to try to implement using whatever solution works best. As that seems to be missing the current argument of if AA can or can not be implemented using SELinux or something totally different should be stopped. So, AA developers, do you have such a document anywhere? I know there are some old research papers, do they properly describe the current model you are trying to implement here? thanks, greg k-h -
In particular, to layer AppArmor on top of SELinux, the following
problems must be addressed:
* New files: when a file is created, it is labeled according to the
type of the creating process and the type of the parent directory.
Applications can also use libselinux to use application logic to
relabel the file, but that is not 'mandatory' policy, and fails in
cases like cp and mv. AppArmor lets you create a policy that e..g
says "/home/*/.plan r" to permit fingerd to read everyone's .plan
file, should it ever exist, and you cannot emulate that with SELinux.
* Renamed Files: Renaming a file changes the policy with respect to
that file in AA. To emulate this in SELinux, you would have to
have a way to instantly re-label the file upon rename.
* Renamed Directory trees: The above problem is compounded with
directory trees. Changing the name at the top of a large, bushy
tree can require instant relabeling of millions of files.
* New Policies: The SEEdit approach of compiling AA profiles into
SELinux labels involves computing the partition set of files, so
that each element of the partition set is unique, and corresponds
to all the policies that treat every file in the element
identically. If you create a new profile that touches *some* of
the files in such an element, then you have to split that
synthetic label, re-compute the partition set, and re-label the
file system.
* File Systems That Do Not Support Labels: The most important being
NFS3 and FAT. Because they do not support labels at all, SELinux
has to give you an all-or-nothing access control on the entire
remote volume. AA can give you nuanced access control in these
file systems.
You could support all of these features in SELinux, but only by adding
an in-kernel file matching mechanism similar to AppArmor. It would
basically load an AppArmor policy into the kernel, label files as the...A daemon using inotify can "instantly"[1] detect this and label the file Same daemon can do this. And yes, it might take a ammount of time, but the times that this happens in "real-life" on a "production" server is SELinux already provides support for the whole mounted filesystem, which, in real-life testing, seems to be quite sufficient. Also, the SELinux developers are working on some changes to make this a bit more fine-grained. See also Stephan's previous comments about NFSv3 client directories and No, do the labeling in userspace with a daemon using inotify to handle the changing of the files around. Or has this whole idea of a daemon been disproved already with a prototype somewhere that failed? If not, a simple test app would not be that hard to hack up. Maybe I'll see if I can do it during the week of June 24 :) thanks, greg k-h -
Hi! And before you scream "races", take a look. It does not actually add Or just create the files with restrictive labels by default. That way ...and no, race there is not important. Attacker may have opened the file under old name and is keeping open file descriptor. So this does And now, if you move a tree, there will be old labels for a while. But this does not matter, because attacker could be keeping file descriptors. Only case where attacker _can't_ be keeping file descriptors is newly created files in recently moved tree. But as you already create files with restrictive permissions, that's okay. Yes, you may get some -EPERM during the tree move, but AA has that problem already, see that "when madly moving trees we sometimes construct path file never ever had". Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -
Pavel, please focus on the current AppArmor implementation. You're remembering a flaw with a previous version of AppArmor. The pathnames constructed with the current version of AppArmor are consistent and correct. Thanks.
Ok, I did not know that this got fixed. How do you do that? Hold a lock preventing renames for a whole time you walk from file to the root of filesystem? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -
We've improved d_path() to remove many of its previous shortcomings: eb3dfb0cb1f4a44e2d0553f89514ce9f2a9fcaf1
From my limited knowledge of SELinux, this is the default today so this would happen by default. Anyone with more SELinux experience want to Exactly. I can't think of a "real world" use of moving directory trees around that this would come up in as a problem. Maybe a source code control system might have this issue for the server, but in a second or two everything would be working again as the new files would be relabled correctly. Can anyone else see a problem with this that I'm just being foolish and missing? thanks, greg k-h -
We have built a label-based AA prototype. It fails because there is no You are remembering old behavior. The current AppArmor generates only correct and consistent paths. If a process has an open file descriptor to such a file, they will retain access to it, as we described here: http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/techdoc.pdf Under the restorecon-alike proposal, you have a HUGE open race. This post http://bugs.centos.org/view.php?id=1981 describes restorecon running for 30 minutes relabeling a file system. That is so far from acceptable that it is silly. Of course, this depends on the system in question, but restorecon will necessarily need to traverse whatever portions of the filesystem that have changed, which can be quite a long time indeed. Any race condition Consider this case: We've been developing a new web site for a month, and testing it on the server by putting it in a different virtual domain. We want to go live at some particular instant by doing an mv of the content into our public HTML directory. We simultaneously want to take the old web site down and archive it by moving it somewhere else. Under the restorecon proposal, the web site would be horribly broken until restorecon finishes, as various random pages are or are not accessible to Apache. In a smaller scale example, I want to share some files with a friend. I can't be bothered to set up a proper access control system, so I just mv the files to ~crispin/public_html/lookitme and in IRC say "get it now, going away in 10 minutes" and then move it out again. Yes, you can manually address this by running "restorecon ~crispin/public_html". But AA does this automatically without having to run any commands. You could get restorecon to do this automatically by using inotify. But to make it as general and transparent as AA is now, you would have to run inotify on every directory in the system, with consequences for kernel memory and performance. This problem does not exist for SELinux, b...
30 minutes during installation does not seem "silly" to me. And that race does not make it insecure, because of the open file You seem to imply it is security related, it is not. I can have open And you do that exactly how, without the race? I do not think ve have three_way_rename(name1, name2, name3) system call. Notice that 1) mv can take minutes already if you move cross filesystem. 2) this is easily avoided by mv-ing somewhere with "same" permissons, Talking about dead ends... "just put path-based security module into kernel" recently got pretty strong "NACK" from Christoph Hellwig (see TOMOYO Linux thread), and I believe there was similar comment from Al Viro in past. That seems to me as dead-endy as it gets. "mv takes 30 minutes" is road slightly covered with bushes... compared to that. So we can either forget about AA completely, or take a way Christoph did not "NACK". restorecond is such a way, and with inotify it should be acceptable. find does _not_ take that long, not even for git trees. pavel@amd:/data/l/linux$ time find . > /dev/null 0.04user 0.37system 11.50 (0m11.504s) elapsed 3.56%CPU (If you wanted to be super-nice, you could introduce rename() helper into glibc, that would do re-labeling synchronously, and only return when it is done. All the nice applications call glibc anyway, and all the exploits can't take advantage of it, because it is secure already.). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -
I've caught up on this thread with growing disbelief while reading the mails, so much that I've found it hard to decide where to reply to. So people are claiming that AA is ugly, because it introduces pathnames and possibly a regex interpreter. Ok, taste differs. We've got many different flavours of filesystems in the kernel because of that. However, the suggested cure makes me cringe. You're saying that relabeling file(s) from user-space after a rename is a possible solution. This breaks POSIX - renames must be atomic. It is possibly insecure; if this is fixed by making a rename automatically default to restrictive permissions, it'll be even more inconvenient. It will break application= s which expect to be able to access the file(s) immediately after a rename. It is slow, and can possibly cause a lot of disk access. Possibly over NFS or via slow disks. By going through user-space - whic= h could block and introduce all sorts of memory deadlocks (compared to that deadlock, a regex is harmless.) (I also wonder how you propose to relabel files on a r/o mount if the policy changes, btw; or if the NFS mount is made available on several nodes w/different permissions.) AA only enforces user-space defined policy - the argument that policy doesn't belong into the kernel is bull. Adding a wrapper to glibc to block until relabeling is complete? "Let's first do the implementation and later worry about performance."? "The timing window is neglible."? "30 minutes during installation does not seem silly."? You _must_ be kidding. The cure is worse than the problem. If that is the only way to implement AA on top of SELinux - and so far, noone has made a better suggestion - I'm convinced that AA has technica= l merit: it does something the on-disk label based approach cannot handle= , and for which there is demand. The code has improved, and continues to improve, to meet all the coding style feedback except the bits which are essential to AA's function (like the pathname lookup ...
inconvenient, yes, insecure, no. I believe AA breaks POSIX, already. rename() is not expected to change permissions on target, nor is link link. And yes, both of these make What demand? SELinux is superior to AA, and there was very little demand for AA. Compare demand for reiser4 or suspend2 with demand for Which are exactly the bits Christoph Hellwig and Al Viro vetoed. http://www.uwsg.iu.edu/hypermail/linux/kernel/0706.1/2587.html . I believe it takes more than "2 users want it" to overcome veto of VFS maintainer. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -
well, if you _really_ want people who are interested in this to do weekly "why isn't it merged yet you $%#$%# developers" threads that can be arranged. the people who want this have been trying to be patient and let the system work. if it takes people being pests to get something implemented it can so you are saying that _any_ pathname based solution is not acceptable to the kernel, no matter what? David Lang -
You'd have to ask Christoph the same question. AFAICT, reconstructing full path then basing security on that is a no-no. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -
Please. We're so not going down _that_ route. -
Well, only if you use the most restrictive permissions. And then you'll
suddenly hit failure cases which you didn't expect to, which can
AA is supposed to allow valid access patterns, so for non-buggy apps +
policies, the rename will be fine and does not change the (observed)
permissions.
The time window in the rename+relabel approach however introduces a slo=
t
SELinux is superior to AA for a certain scenario of use cases; as we ca=
n
A veto is not a technical argument. All technical arguments (except for
"path name is ugly, yuk yuk!") have been addressed, have they not?
Regards,
Lars
--=20
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N=FCrnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wil=
de
-That still breaks POSIX, right? Hopefully it will not break any apps, The scenario where it does not seem superior is "I have system with AA There still is "it does not work with long pathnames". Plus IIRC we have something like "AA has to allocate path-sized buffers along every syscall". I guess Al Viro or Christoph Hellwig would be able to detail on that. I don't think they are vetoing stuff for fun. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -
No, it does not break POSIX.
Unless, of course, there's a bug in the policy or in the program. Bugs
are generally not covered by POSIX, for some strange reason.
(The argument that POSIX codifies implementation bugs in Unix(tm)
That is an implementation bug though. I'm sure we have other bugs in th=
e
kernel too - this isn't a design flaw.=20
(If people are allowed to thinair solutions for implementing AA on top
of SELinux, I can thinair that this can be solved by reverse-matching
the dentry tree against the policy as the path is traversed and
constructed, requiring a constant sized buffer.)
Regards,
Lars
--=20
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N=FCrnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wil=
de
-Indeed there are a few solutions to "fix" this implementation "bug", of which reverse matching is one. For reverse matching the policy tables would become larger. Reverse matching wouldn't need any additional buffer for enforcement but would still fall back to d_path for logging. But we would still require the changes to the vfs and also a way to safely walk the tree backwards. So we would need to either export the namespace semaphore or add a generic walking function which we could pass a hook function to.
AppArmor doesn't actually provide confinement, because it only operates on filesystem objects. What you define in AppArmor policy does _not_ reflect the actual confinement properties of the policy. Applications can simply use other mechanisms to access objects, and the policy is effectively meaningless. You might define this as a non-technical issue, but the fact that AppArmor simply does not and can not work is a fairly significant consideration, I would imagine. - James -- James Morris <jmorris@namei.org> -
ss.
Only if they have access to another process which provides them with
that data.
And now, yes, I know AA doesn't mediate IPC or networking (yet), but
If I restrict my Mozilla to not access my on-disk mail folder, it can't
get there. (Barring bugs in programs which Mozilla is allowed to run
unconfined, sure.)
If the argument is that AA provides somewhat different semantics - and
for some use cases "weaker" ones - than SE Linux, that is undoubtly
true. However, it appears to be the case that those are the differences
which make AA's model different from SELinux as well, so it appears a
trade-off best left to the admin / user to choose what fits their needs
best.
Regards,
Lars
--=20
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N=FCrnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wil=
de
-Or can access the data under a different path to which their profile does give them access, whether in its final destination or in some The incomplete mediation flows from the design, since the pathname-based mediation doesn't generalize to cover all objects unlike label- or attribute-based mediation. And the "use the natural abstraction for each object type" approach likewise doesn't yield any general model or anything that you can analyze systematically for data flow. The emphasis on never modifying applications for security in AA likewise has an adverse impact here, as you will ultimately have to deal with application mediation of access to their own objects and operations not directly visible to the kernel (as we have already done in SELinux for D-BUS and others and are doing for X). Otherwise, your "protection" of Um, no. It might not be able to directly open files via that path, but showing that it can never read or write your mail is a rather different matter. -- Stephen Smalley National Security Agency -
No the "incomplete" mediation does not flow from the design. We have deliberately focused on doing the necessary modifications for pathname based mediation. The IPC and network mediation are a wip. We have never claimed to be using pathname-based mediation IPC or networkin= g. The "natural abstraction" approach does generize well enough and will yes of course, we realize that dbus and X must be trusted applications, this to will happen. But it will happen piece meal, something about Actually it can be analyzed and shown. It is ugly to do and we currently don't have a tool capable of doing it, but it is possible.
The fact that you have to go back to the drawing board for them is that I think we must have different understandings of the words "generalize" and "analyzable". Look, if I want to be able to state properties about data flow in the system for confidentiality or integrity goals (my secret data can never leak to unauthorized entities, my critical data can never be corrupted/tainted by unauthorized entities - directly or indirectly), then I need to be able to have a common reference point for my policy. When my policy is based on different abstractions (pathnames, IP addresses, window ids, whatever) for different objects, then I can no longer identify how data can flow throughout the system in No, it isn't possible when using ambiguous and unstable identifiers for the subjects and objects, nor when mediation is incomplete. -- Stephen Smalley National Security Agency -
or it just means that the tool to regulat the network is different from the tool to regulate the filesystem. oh, by the way. that's how the rest of the *nix world works. firewall rules apply to networking, filesystem permissions and ACLs apply to the filesystem. this is like climing that the latest improvement to ipsec shouldn't go in becouse it down't allow you to handle things the same way that you handle if you are doing a system-wide analysis then you are correct. the AA approach is to start with the exposed items and limit the damage that can be done to you. sysadmins already think in terms of paths and what can access that path (directory permissions), AA extends this in a very natural way and doesn't require any special tools or extra steps for normal administration. As a result sysadmins are far more likely to use this then they are to touch anything that requires that they do a full system analysis before they start. another advantage is that since the policies are independant of each other it becomes very easy for software to include sample policies with the it is possible to say that without assistance from an outside process the process cannot access the files containing your mail. if there is some other method of accessing the content no filesystem-level thing can know about it (for example, if another process is a pop server that requires no password). but I don't beleive that SELinux policies as distributed by any vendor would prevent this (yes, it would be possible for a tailored policy to prevent it, but if the policy is so complex that only distro staff should touch it that doesn't matter in real life) David Lang -
That's an interesting claim, however I don't think it holds. AA was
designed to mediate file access in a form which is intuitive to admins.
It's to be expected that it doesn't directly apply to mediating other
I seem to think that this is not what AA is trying to do, so evaluating
it in that context doesn't seem useful. It's like saying a screw driver
isn't a hammer, so it is useless because you have a nail.
Regards,
Lars
--=20
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N=FCrnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wil=
de
-Again, in that case, please remove all uses of the terms "mandatory access control", "confinement" and "integrity protection" from AA documentation and code. -- Stephen Smalley National Security Agency -
This feels quite a lot like a repeat of the discussion at the kernel summit. There are valid uses for path based security, and if they don't fit your needs, please don't use them. But, path based semantics alone are not a valid reason to shut out AA. -chris -
The validity or otherwise of pathname access control is not being discussed here. The point is that the pathname model does not generalize, and that AppArmor's inability to provide adequate coverage of the system is a design issue arising from this. Recall that the question asked by Lars was whether there were any outstanding technical issues relating to AppArmor. AppArmor does not and can not provide the level of confinement claimed by the documentation, and its policy does not reflect its actual confinement properties. That's kind of a technical issue, right? - James -- James Morris <jmorris@namei.org> -
I'm sorry, but I don't see where in the paragraphs above you aren't making a general argument against the pathname model. -chris -
There are two distinct concepts here. A. Pathname labeling - applying access control to pathnames to objects, rather than labeling the objects themselves. Think of this as, say, securing your house by putting a gate in the street in front of the house, regardless of how many other possible paths there are to the house via other streets, adjoining properties etc. Pathname labeling and mediation is simply mediating a well-known path to the object. In this analogy, object labeling would instead ensure that all of the accessible doors, windows and other entrances of the house were locked, so that someone trying to break in from the rear alley would not get in simply by bypassing the front gate and opening any door. What you do with AppArmor, instead of addressing the problem, is just redefine the environment along the lines of "set your house into a rock wall so there is only one path to it". B. Pathname access control as a general abstraction for OS security. Which is what was being discussed above, in response to a question from Lars about technical issues, and that this _model_ doesn't generalize to the rest of the OS, regardless of whether you think the mechanism of pathname labeling itself is appropriate or not. In any case, clarifying such a distinction should not obscure the central issue, which is: AppArmor's design is broken. General users, many kernel developers, and even security researchers who have not yet looked under the covers [1], are probably unaware that the confinement claims being made about AppArmor's confinement capabilities are simply not possible with either its model or implementation. To quote from: http://www.novell.com/linux/security/apparmor/ "AppArmor gives you network application security via mandatory access control for programs, protecting against the exploitation of software flaws and compromised systems. AppArmor includes everything you need to provide effective containment for programs (includin...
I'm sorry, but I don't see where in the paragraphs above you aren't making a general argument against the pathname model. I'm not trying to get into that discussion (I'm smart enough to know I'm far too stupid to hold my own there). I do understand that AA is different from selinux, and that you have valid points about the level and type of protection that AA offers. But, this is a completely different discussion than if AA is solving problems in the wild for its intended audience, or if the code is somehow flawed and breaking other parts of the kernel. We've been over the "AA is different" discussion in threads about a billion times, and at the last kernel summit. I think Lars and others have done a pretty good job of describing the problems they are trying to solve, can we please move on to discussing technical issues around that? -chris -
Actually, I surprised Lars a lot by telling him ln /etc/shadow /tmp/ allows any user to make AA ineffective on large part of systems -- in internal discussion. (It is not actually a _bug_, but it is certainly unexpected). (Does it surprise you, too? I'm pretty sure it would surprise many users). James summarized it nicely: # The design of the AppArmor is based on _appearing simple_, but at the # expense of completeness and thus correctness. If even Lars can be surprised by AAs behaviour, I do not think we can say "AA is different". I'm afraid that AA is trap for users. It appears simple, and mostly does what it is told, but does not do _what user wants_. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -
Pavel, no, you did not. You _did_ surprise me by misquoting me so badly=
,
though.
I agreed that actions by not mediated processes can interfere with
mediated processes. That is a given. So you do not give them free acces=
s
to a world writable directory.
Regards,
Lars
--=20
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N=FCrnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wil=
de
-no, it doesn't surprise me in the least. AA is controlling access to the thing called /etc/shadow, if you grant access to it in other ways you bypass the restrictions. if you follow the ln /etc/shadow /tmp/ with chmod 777 /tmp/shadow the system is completely insecure. this is standard stuff that normal sysadmins expect. it's only people who have focused on the label approach who would expect it to be any I thought it had been made very clear that hard links like this were a potential way around the restrictions, which is why controlled tasks are not allowed to do arbatrary hard links. David Lang -
Is its intended audience aware of its limitiations? Lars has just acknowledged that it does not implement mandatory access control, for one. Until people understand these issues, they certainly need to be addressed I don't believe that people at the summit were adequately informed on the issue, and from several accounts I've heard, Stephen Smalley was Keep in mind that this current thread arose from Greg KH asking about whether AppArmor could effectively be implemented via SELinux and userspace labeling. Some of us took the time to perform analysis and then provide feedback on this, in good faith. The underlying issues only came up again in response to an inflammatory post by Lars. If you want to avoid discussions of AppArmor's design, then I suggest taking it up with those who initiate them. - James -- James Morris <jmorris@namei.org> -
there are always going to be people who misunderstand things. by this logic nothing can ever be merged that can be misused. at least some of the intended audience (including me) do understand the limits and still consider the result useful. David Lang -
It is definitely useful to clearly understand the intended AA use cases
I'm sure people there will have a different versions of events. The
one part that was discussed was if pathname based security was
useful, and a number of the people in the room (outside of
novell) said it was. Now, it could be that nobody wanted to argue
anymore, since most opinions had come out on one list or another by
then.
But as someone who doesn't use either SElinux or AA, I really hope
we can get past the part of the debate where:
while(1)
AA) we think we're making users happy with pathname security
SELINUX) pathname security sucks
So, yes Greg got it started and Lars is a well known trouble maker, and
I completely understand if you want to say no thank you to an selinux
based AA ;) The models are different and it shouldn't be a requirement
that they try to use the same underlying mechanisms.
-chris
-(Hopefully I'll not be fired for this. :-) Yes, we _are_ making users happy with AA. Questions is if we are making them secure. :-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -
Indeed. The trouble is that's too high level compared with the actual implementation details. AA is stalled because it has failed to get VFS support for it's model. I don't see a nice way out unless it changes it's notion of policy language (globbing is the tough one) or gets traction to pass dentry/vfsmount all the way down. Paths are completely relevant for security, esp. when considering the parent dir and the leaf (as in forward lookup case). Retroactively creating the full path is at the minimum ugly, and in the worst case can be insecure Yes. Please. Both parties are miserably failing the sanity test. Doing the same thing over and over and expecting different results. AA folks: deal with the VFS issues that your patchset have in a palatable way (which does not include passing NULL when it's inconvenient to do otherwise). You've already missed an opportunity with Christoph's suggestions for changes in NFS. I know you've considered many alternative approaches and consistently hit dead ends. But please note, if you have coded yourself into a corner because of your policy language, that's your issue to solve, not ours. SELinux folks: do something useful rather than quibbling over the TCSEC definition of MAC and AA's poor taste in marketing literature. Here's some suggestions: 1) Make SELinux usable (it's *still* the number one complaint). While this is a bit of a cheap shot, it really is one of the core reasons AA advocates exist. 2) Work on a variant of Kyle's suggestion to squash the relevancy of AA. 3) Write an effective exploit against AA that demonstrates the fundamental weakness of the model (better make sure it's not also an issue for targetted policy). thanks, -chris -
To do pathname-based access control in any way, the LSM must be able to obtain the pathname of an accessed object. The discussion should be about the best way for an LSM to obtain the pathname of an object being accessed. To find the pathname of the object, LSM needs the VFS mount point data. The VFS owns this information, so the question is the best way to convey it from VFS to relevant LSM hooks. We are agnostic about how to get that mount point data, but AFAICT saying that LSM can't see the mount point data at all is equivalent to rejecting pathname based access control The reverse path construction has been criticized for being both broken and counter-intuitive. Our secure d_path patch fixes the "broken" part, it now securely reconstructs the path. The counter-intuitive is because forward construction of the pathname has unexpected costs, making the John Johansen posted a patch (written by Andreas Gruenbacher) that introduced a nameidata2 data structure to try to solve the conditional null passing problem, but it received no comment. A proper fix to this problem is clearly desirable, but it also is clearly a defect in NFS and fixing it is a lot of work; why does AA have to stay outside the kernel until NFS is fixed, when it can easily adapt to the problem until it is I think it is a little more fundamental than that. If you are going to do pathname based access control at all, you need access to sufficient information to compute the path name. Can we have a discussion about the best way to do that? Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oftc.net/#apparmor -
This thread is amazing. With so many smart people's precious time, What are the results? What are the issues anyway? Is anyone happy? (I'm not and I assume Chris is not) Yes, "waste of time" is taking place here, but it's not for "pathname-based MAC" but for "wrongly posted messages", I believe. I'm a relatively new to this ml, let me ask. Is this ml a place of judge or battle? (not to help or support?) Nothing is perfect, so we can work to make things to better, right? I have suggestions: Let's clarify issues first. - problems (or limitations) of pathname-based MAC - advantages of pathname-based MAC - how can pathname-based MAC supplement label based (Stephen, James and Kyle, please help) Let's start the arguments again if we get the issues. Threads should be definitely separated per issue and a assigning a chair may help. Above issues are independent of SELinux. We should not *compare* SELinux and AA, that can cause a problem. Every software has shortages that's why we need to work and we can make progress. For some issues we may need to compare them, in that case moderators would help. BTW I have posted a RFC of TOMOYO Linux that is another pathname-based MAC. http://lkml.org/lkml/2007/6/13/58 AA and TOMOYO Linux have BoF sessions at OLS2007, so it would be a great opportunity to *talk* over the issues. What I want to say is "let's make progress and help each other to make Linux better". Thank you, Toshiharu Harada -- Toshiharu Harada haradats@nttdata.co.jp -
Well, I crated a Wiki page. If it helps, please feel free to use it. I mean I would like people to add your issues here. It's wiki, so you are welcome to modify everything. http://tomoyo.sourceforge.jp/wiki-e/?MAC-ISSUES If ml is better, I have no objections. Cheers, Toshiharu Harada -
As we have previously stated we are not using pathnames for IPC. The use of pathnames for file access mediation is not a design issue that in anyway prevents us from extending AppArmor to mediate IPC or networking. The current focus is making the revision necessary for AppArmor's file mediation at which point we can focus on finishing of the network AppArmor currently controls file and capabilities, which was explicitly stated in the documentation submitted with the patches. And it has been posted before that network and IPC mediation are a wip.
So if the document said "confinement with respect to direct file access and POSIX.1e capabilities" and that list got extended as AA got new confinement features, would that address your issue? Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oftc.net/#apparmor -
That would certainly help, although one might quibble with the use of the word "confinement" at all wrt AppArmor (it has a long-established technical meaning that implies information flow control, and that goes beyond even complete mediation - it requires global and persistent protection of the data based on its properties, which requires stable and unambiguous identifiers). -- Stephen Smalley National Security Agency -