login
Search
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 aa_dfa *dfa, void *blob, size_t ...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 ...
That's a really good point, is there a description of the AA "model" anywhere that we could see to determine if there really is a way to possibly use the current SELinux internals to show this model to the user? thanks, greg k-h -
Hmm, techdoc.pdf (attached) is supposed to describe this "model", but it is more of "AA works like this" with no explanations.... and includes (probably unwanted) quirks like various races during path resolution. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
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 ...
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 -
I agree that the in-kernel implementation could use different abstractions than user-space, provided that the underlying implementation details can be hidden well enough. The key phrase here is "if possible", and in fact "if possible" is much too strong: very many things in software are possible, including user-space drives and a stable kernel module ABI. Some things make sense; others are genuinely bad ideas while still possible. The things in my reply you chose not to quote make up the essential part of the model, argue why mapping from an AppArmor-like user-space to a label-based in-kernel model is fundamentally hard, how implementation details cannot be hidden, and how such a mapping would lead to disadvantages no I did not pull all of this out of my hat ad hoc. The AppArmor team spent a fair amount of time researching various ways how AppArmor-like semantics could be implemented on top of SELinux, as well as ways how AppArmor could be implemented better. We *really* tried hard. The reason why we are still proposing this non-SELinux approach is because none of the alternatives worked out. If things were as simple as mapping an AppArmor frontend to the SELinux backend, even with extensions to the SELinux backend (and I know that it wouldn't be impossible to extend SELinux in reasonable ways), this would indeed be nice. The issues that SEEdit is having unfortunately only confirm There is no need to start all over implementing something from scratch. People have already tried emulating AppArmor on top of SELinux, and SEEdit is the current best result. All it takes is the time to understand the SELinux and AppArmor models. From there it is not hard to see that SEEdit does the best it can do, and how it is just not a good idea. There are a few things that could be improved with additional SELinux in-kernel infrastructure, but the We wrote an AppArmor technical documentation, and it was posted as part of the last two AppArmor submissions. It ...
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 ...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 -
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 ...
How does inotify not work here? You are notified that the tree is moved, your daemon goes through and relabels things as needed. In the meantime, before the re-label happens, you might have the wrong label on things, but "somehow" SELinux already handles this, so I think you Ok, so we fix it. Seriously, it shouldn't be that hard. If that's the Agreed, so we fix that. There are ways to speed those kinds of things up quite a bit, and I imagine since the default SELinux behavior doesn't use restorecon in this kind of use-case, no one has spent the time to do Usually you don't do that by doing a 'mv' otherwise you are almost guaranteed stale and mixed up content for some period of time, not to I'm saying that the daemon will automatically do it for you, you don't What "kernel memory and performance" issues are there? Your SLED machine already has inotify running on every directory in the system No, that's not the issue here. The issue is if we can use the model that AA is exporting to users and apply it to the model that the kernel Not really, LSM is there because originally people thought that a general-purpose "hook" layer would be useful for implementing different security models. But for those types of models that do not map well to internal kernel structures, perhaps they should be modeled on top of a security system that does handle the internal kernel representation of No, git servers are only storing the sha files, not the "live" tree. Well, if you want to waste space on your server you might have a copy of Great, have any code I can look at? It would be nice to start with an already working implementation that is only slow instead of trying to You still haven't answered Stephen's response to NFSv3, so until then, please don't trot out this horse. thanks, greg k-h -
SELinux does not relabel files when containing directories move, so it is not a problem they've chosen to face. How well does inotify handle running attached to every directory on a Restorecon traverses the filesystem from a specific down. In order to apply to an entire system (as would be necessary to try to emulate AppArmor's model using SELinux), restorecon would need to run on vast portions of the filesystem often. (mv ~/public_html ~/archived; or tar zxvf linux-*.tar.gz, etc.) The time for restorecon is probably best imagined as a kind of 'du' that also updates extended attributes as it does its work. It'd be very I beg to differ. :)
Look at SLED and Beagle (taking the indexing logic out of the equation.) It runs good enough that a major Linux vendor is willing to stake its Ok, so we optimize it. Putting speed issues aside right now as a "mere" implementation details, I'm looking for logical reasons the AA model The Beagle index backend is known to slow things down at times, yes, but is that the fault of the inotify watches, or the use of mono and a big-ass database on the system at the same time? In the original inotify development, the issue was not inotify at all, unless you have some newer numbers in this regard? And Crispin mentioned that you all already implemented this. Do you have the code around so that we can take a look at it? thanks, greg k-h -
It's a deliberate design choice, and follows traditional Unix security logic. DAC permissions don't change on every file in the subtree when you mv directories, either. - James -- James Morris <jmorris@namei.org> -
restorecon can most definitely be improved. - James -- James Morris <jmorris@namei.org> -
How exactly are struct vfsmount and struct dentry not in-kernel structures? Andreas -
That's what greg is talking about, AFAICT. Normal kernel code uses struct vfsmount + struct dentry. AA uses... guess what... char pathname[HUGE_VALUE]. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -
Ok then ...
I'm actually unclear on what the question is. Stephen appears to be
thinking of confining the NFS server daemon, and our intended use case
is to use AppArmor to confine applications that access data on NFS clients.
* Each NFS *client* machine has a view of the NFS mount point that
is consistent for that client.
* The AA confinement is of the application accessing the NFS mount
on the client, *not* the NFS server daemon.
* The fact that the views of multiple clients are different from
each other is irrelevant, because we are confining applications on
the client, not the NFS server daemon.
* As noted in Andreas' technical document
http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/techdoc.pdf
there is no purpose to confining the NFS server daemon; it is a
kernel process, and if it mis-behaves, it can completely subvert
any kernel security policy, including AA and SELinux.
Since this point seems to be subtle, here's a motivating example.
Consider I have a diskless workstation, and my home dir /home/crispin is
NFS mounted from a big NAS server over there. I like to run my FireFox
confined, so that it only has access to /home/crispin/.mozilla/** and
/home/crispin/Downloads/** so that if my browser is compromised, the
attacker doesn't get to my /home/.ssh* stuff.
Yes, the data served over NFS is vulnerable to a local network attack,
but that is not what AA is preventing here. The threat is coming from
attacks that make the web browser misbehave.
Under SELinux, I either give the web browser access to all of
/home/crispin (the entire mount point) or none of it. Under AA, the
pathname specification works fine, we can control which directories on
the mount point the application can access.
The same argument applies to server applications that access data served
NFS mount points. Consider a large application server that hosts all my
enterprise resource management stuff, and a large NAS server ...how do you 'fix' the laws of physics? the problem is that with a directory that contains lots of files below it you have to access all the files metadata to change the labels on it. it can take significant amounts of time to walk the entire three and change on the contrary, useing 'mv' is by far the cleanest way to do this. mv htdocs htdocs.old;mv htdocs.new htdocs this makes two atomic changes to the filesystem, but can generate thousands to millions of permission changes as a result. David Lang -
Ok, so mv gets slower for big trees... and open() gets faster for deep trees. Previously, open in current directory was one atomic read of directory entry, now it has to read directory, and its parent, and its parent parent, and its... (Or am I wrong and getting full path does not need to bring anything in, not even in cache-cold case?) So, proposed solution has different performance tradeoffs, but should still be a win -- opens are more common than moves. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -
You are wrong, indeed. The dentries in the dcache are connected to the dcache through their parent dentry pointers, which means that the parent dentries are always in memory, too. No I/O is involved for walking up dentry trees. (Caveat: nfsd does allow disconnected dentries. It does not make sense to try confining an in-kernel daemon though, an no user process can ever access a dentry before it gets connected (lookup does that), so this difference is irrelevant here.) -
Let's worry about speed issues later on when a working implementation is produced, I'm still looking for the logical reason a system like this can not work properly based on the expected AA interface to users. thanks, greg k-h -
no it doesn't, SELinux as-is should take no action when the above command is run, but SELinux implementing path-based permissions will have to if you are willing to live with the race conditions from the slow (re)labeling and write the software to scan the entire system to figure out the right policies (and then use inotify to watch the entire system for changes and (re)label the appropriate files) and accept that you can't get any granular security for filesystems that don't nativly support it you could make SELinux behave like AA. but why should they be required to? are you saying that the LSM hooks are not a valid API and should be removed with all future security modules being based on SELinux? David Lang -
You make it sound like such a pretty picture :) Anyway, I don't think there are "race conditions", just a bit of a delay at times for situations that are not common or "normal operations". And as I think the speed issues can be drasticly reduced, I don't think that's a really big deal just yet. I'm trying to determine if there's any logical reason why we can't do this and have yet to see proof of Woah, that's a huge logical jump that I am not willing to make at this point in time. The reason I am proposing this for AA is due to the impeadance between the AA model and how the kernel internally works. A number of core kernel VFS developers have objected to the AA code and changes because of this problem and me and Pavel are here working to try to resolve this in a way that is acceptable to everyone involved (kernel developers and AA developers and AA end users.) I'll leave the whole "LSM should be just replaced with SELinux" discussion for later, as it is not relevant to this current topic at all. thanks, greg k-h -
OTOH, you've performed your labeling up front, and don't have to effectively relabel each file each time on each access, which is what you're really doing with pathname labeling. - James -- James Morris <jmorris@namei.org> -
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 applications 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 - which 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 technical 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 and the ...
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, 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 slot
SELinux is superior to AA for a certain scenario of use cases; as we can
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
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
-
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 the
kernel too - this isn't a design flaw.
(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
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
-
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> -
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
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
-
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 -
Well, yes. That is intentional.
That is an interesting argument, but not what we're discussing here.
Yes. Your use case is different than mine.
Regards,
Lars
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
-
It may very well be unintentional access, especially when taking into IOW, anything that AA cannot protect against is "out of scope". An easy My use case is being able to protect data reliably. Yours? -- Stephen Smalley National Security Agency -
Again, you're saying that AA is not confining unconfined processes.
That's a given. If unconfined processes assist confined processes in
breeching their confinement, yes, that is not mediated.
You're basically saying that anything but system-wide mandatory access
control is pointless.
If you want to go down that route, what is your reply to me saying that
SELinux cannot mediate NFS mounts - if the server is not confined using
SELinux as well? The argument is really, really moot and pointless. Yes,
unconfined actions can affect confined processes.
I'm quite sure that this reply is not AA specific as you try to make it
I want to restrict certain possibly untrusted applications and
network-facing services from accessing certain file patterns, because as
a user and admin, that's the mindset I'm used to. I might be interested
in mediating other channels too, but the files are what I really care
about. I'm inclined to trust the other processes.
Your use case mandates complete system-wide mediation, because you want
full data flow analysis. Mine doesn't.
Regards,
Lars
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
-
The issue arises even for a collection of collaborating confined processes with different profiles, and the collaboration may be intentional or unintentional (in the latter case, one of the confined processes may be taking advantage of known behavior of another process and shared access by both to some resource in order to induce a particular behavior in that process). And remember that confinement isn't just about limiting untrusted processes but also about protecting trusted processes; limiting the inputs and outputs of a trusted process can be just as important to Mandatory access control as historically understood has always meant system-wide. As well as always being based on the security properties of the data (so that global and persistent protection of the data is possible). You can't actually use the terms 'mandatory access control' Sorry, do you mean the "server" as in the "server system" or as in the "server daemon"? For the former, I'd agree - we would want SELinux policy applied on the server as well as the client to ensure that the data is being protected consistently throughout and that the server is not misrepresenting the security guarantees expected by the clients. Providing an illusion of confinement on each client without any corresponding protection on the server system would be very prone to bypass. For the latter, the kernel can only truly confine application code, not in-kernel threads, although we can subject the in-kernel nfsd to permission checking as a robustness check. We've always noted that Every time we've noted an issue with AA, the answer has been that it is out of scope. Yet the public documentation for AA misrepresents the situation and its comparisons with SELinux conveniently ignore its Then yours isn't mandatory access control, nor is it confinement. -- Stephen Smalley National Security Agency -
Point taken; the point remains is that you need at least several
(intentionally or not) cooperating processes. The chances of this are
True. It'd appear that if you want that, you'd specify the AA profile so
that it doesn't include directories/files writable by untrusted
I'm sorry. Again, I'm not responsible for marketing comparisons made by
anyone else, nor do I think they should apply to this discussion where
we're discussing the merits of what AA actually _does_; not what
someone's marketing claims it does - otherwise I'll go dig out marketing
claims about SELinux too ;-)
And, coming at it from that direction, I feel it does something useful.
Note that here we've already strayed from the focus of the discussion;
we're no longer arguing "the implementation is ugly/broken", but you're
claiming "doesn't do what I need" - which I'm not disagreeing with. It
doesn't do what you want. Which is why you have SELinux, and it's going
to stay. Fine.
If we assume that the users who run it do have a need / use case for it
which they can't solve differently, we should really get back to the
discussion of how those needs can be met or provided by Linux in a
I apologize for not using the word "confinement" in the way you expect
it to be used. I certainly don't want to imply it does do things it
doesn't. Keep in mind I'm not a native speaker, so nuances do get lost
sometimes; nor do I have long years of experience in the security
field. Thanks for clearing this up.
So agreed, it is not confinement nor MAC.
Would it be more appropriate if I used the word "restricts" or
"constrains"?
Regards,
Lars
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
-
Kernel flaws aren't something we can address (reliably and in general) via a kernel mechanism. Versus a threat that can be addressed by kernel mechanism, like providing complete mediation and unambiguous access control. There is a difference. And we aren't ignoring the kernel correctness problem - there is separate work in that space, but it Part of the discussion has been whether those users' needs could be solved better via SELinux, whether via improved userspace tools (ala seedit possibly with an enhanced restorecond) or via extended kernel mechanism (ala named type transitions and some kind of inheritance model). It does however seem like there is a fundamental conflict there on renaming behavior; I do not believe that file protections should automatically change in the kernel upon rename and should require explicit userspace action. The question though is whether that renaming behavior in AA is truly a user requirement or a manufactured (i.e. made-up) one, and whether it is truly a runtime requirement or just a policy creation time one (the latter being adequately addressed by userspace relabeling). If that behavior is truly needed (a point I wouldn't concede), then the discussion does reduce down to the right implementation method. There it appears that the primary objection is to regenerating full pathname strings and matching them versus some kind of incremental matching either during lookup itself or via a reverse match as suggested. That discussion is principally one in which the vfs folks should be engaged, Yes. Or simply "controls file accesses and capability usage". -- Stephen Smalley National Security Agency -
I suppose there is also a question of whether that kind of model wouldn't be better implemented as an ACL model with implicit inheritance, e.g. if you specify an ACL on a directory, then all files accessed via that directory are controlled in accordance with that ACL unless they have their own more specific ACL, and if you move one of those files to a different directory, then they automatically pick up the protection of the new parent. Doesn't require the kernel to be matching pathname strings, just walking up the tree to determine the -- Stephen Smalley National Security Agency -
Chapter and verse: TCSEC 3.1.1.4 Mandatory Access Control "The TCB shall enforce a mandatory access control policy over all subjects and storage objects under its control." Chapter and verse: TCSEC 3.2.1.4 Mandatory Access Control "The TCB shall enforce a mandatory access control policy over all resources that are directly or indirectly accessible by subjects external to the TCB." The first reference is in the definition of a B1 system, while the second is for a B2 system. It was made clear to those of us doing TCSEC evaluations that there is a very real distintion between these two requirements. In the history that I've been through, starting in 1987, the B1 requirement has been read to allow for things that are not storage objects to be uncontrolled while the B2 requirement does not. If everything is a storage object, which is the approach everybody took, yes, you're looking at system wide. If, on the other hand, you were to take a different model approach and say that networking does not use storage objects you would not have to account for them under the B1 rules, while you would still have to for B2. Historically, no one succeeded with B2, and the mindset of B1 prevailed. So, historically, the understanding was that it was easier to declare everything a storage object and code up some MAC for it than it was to provide a security model that explained networking as it really works. I suggest that if AA wants to declare that as far as they are concerned sockets, ports, and packets are none of them storage objects but are instead pregnant weasels that is their peragotive as system designers and that a B1 evaluation team would have accepted that, provided sufficient evidence and explaination of the relevence of pregnant weasels was provided. It would not have worked at B2, but historically everyone understood that B2 was out of reach. Stephen is correct in that historically everyone implemented system that put everything under MAC, but is not in that it ...
So.. your use case is what? If an AA user asked you to protect his mail from his browser I'm sure you'd truthfully answer "no, we can't do that but we can protect the path to your mail from your browser".. I think not. One need only look at the wonderful marketing literature for AA to see what you are telling people it can do, and your above statement isn't consistent with that, sorry. -
I'm sorry. I don't work in marketing. -- Teamlead Kernel, SuSE Labs, Research and Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) "Experience is the name everyone gives to their mistakes." -- Oscar Wilde -
remember, the policies define a white-list so if a hacker wants to have mozilla access the mail files he needs to get some other process on the sysstem to create a link or move a file to a path that mozilla does have access to. until that is done there is no way for mozilla to access the mail through the filesystem. other programs could be run that would give mozilla access to the mail contents, but it would be through some other path that the policy permitted mozilla accessing in the first place. David Lang -
Or through IPC or the network, that is the point, filesystem only coverage doesn't cut it; there is no way to say the browser can't access the users mail in AA, and there never will be. -
The argument that AA doesn't mediate what it is not configured to
mediate is correct, yes, but I don't think that's a valid _design_ issue
We have a variety of filtering mechanisms which are specific to a
domain. iptables filters networking only; file permissions filter file
access only. This argument is not really strong.
<tangent>
If you're now arguing the "spirit of Unix", I can turn your argument
around too: the Unix spirit is to have smallish dedicated tools. If AA
is dedicated to mediating file access, isn't that nice!
AA _could_ be extended to mediate network access and IPC (and this is
WIP). If we had tcpfs and ipcfs - you know, everything is a filesystem,
the Linux spirit! ;-) - AA could mediate them as well.
</tangent>
However, we're discussing the way it mediates file accesses here,
for which it appears useful and capable of functionality which SELinux's
approach cannot provide.
Regards,
Lars
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
-
correct, but we are talking about what a confined process can get to AA can be extended to cover these things in the future. remember 'release early release often'? how about 'perfect is the enemy of good enoug'? at this point they're trying to get the initial implementation in so that people can start takeing advantage of it. As a side effect the cost of maintaining it will decrease, and they can put effort into planning future enhancements. besides, as far as the network communication goes, doesn't netfilter now have a way to make rules for specific processes? if they don't then it could be added, but the details of the implementation would probably be very different from the current AA file controls. how does delaying the acceptance of the current implementation encourage the additional features being added? but to answer your two comments. how does mozilla access your mail over the network without first capturing your password from somewhere? as far as IPC goes, unix sockets are unavailable (AA as-is will control them), so you must be talking about signals or shared memory as the IPC mechanisms that mozilla would use to access your mail. please explain to me what mail client you are useing that exposes your mail via these mechinsms. David Lang -
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 ...
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 -
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> -
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
-
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 -
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 -
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 -
(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 -
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 -
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 -
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 -
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 access
to a world writable directory.
Regards,
Lars
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
-
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 -
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.
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 -
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
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
-
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 -
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 -
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 -
Please. We're so not going down _that_ route. -
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 -
If you share ~crispin/public_html/lookitme by making a hard link, does relabeling approach work? I thought SELinux allows only one label for one file. If AA (on the top of SELinux) tries to allow different permissions to ~crispin/public_html/lookitme and its original location, either one of two pathnames won't be accessible as intended, will it? -
Yes, that's a bug/feature in AA. No, selinux will not be able to emulate that bug/feature. Yes, it is dangerous, as it makes AA mostly useless on multiuser machines. (ln /etc/shadow /tmp is something any user can do, and all you need is to exploit any daemon with access to /tmp). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -
This is entirely controllable via policy. That is, you specify that newly create files are labeled to something safe (enforced atomically at the kernel level), and then your userland relabeler would be invoked via inotify to relabel based on your userland pathname specification. This labeling policy can be as granular as you wish, from the entire filesystem to a single file. It can also be applied depending on the process which created the file and the directory its created in, ranging from all processes and all directories, to say, just those running as user_t in directories labeled as public_html_t (or whatever). - James -- James Morris <jmorris@namei.org> -
Oh great, then things like source code control systems would have no problems with new files being created under them, or renaming whole trees. So, so much for the "it's going to be too slow re-labeling everything" issue, as it's not even required for almost all situations :) thanks for letting us know. greg k-h -
It depends -- I think we may be talking about different things. If you're using inotify to watch for new files and kick something in userspace to relabel them, it could take a while to relabel a lot of files, although there are likely some gains to be had from parallel relabeling which we've not explored. What I was saying is that you can use traditional SELinux labeling policy underneath that to ensure that there is always a safe label on each file You could probably get an idea of the cost by running something like: $ time find /usr/src/linux | xargs setfattr -n user.foo -v bar On my system, it takes about 1.2 seconds to label a fully checked out kernel source tree with ~23,000 files in this manner, on a stock standard ext3 filesystem with a SATA drive. - James -- James Morris <jmorris@namei.org> -
Yeah, that should be very reasonable. I'll wait to see Crispin's code to work off of and see if I can get it to approach that kind of speed. thanks, greg k-h -
That's an eternity for that many files to be improperly labeled. If, and the "if" didn't originate with me, your policy is demonstrably correct (how do you do that?) for all domains you could claim that the action is safe, if not ideal. I can't say if an evaluation team would buy the "safe" argument. They've been known to balk before. Casey Schaufler casey@schaufler-ca.com -
To clarify: We are discussing a scheme where the underlying SELinux labeling policy always ensures a safe label on a file, and then relabeling newly created files according to their pathnames. There is no expectation that this scheme would be submitted for certification. Its purpose is to merely to provide pathname-based labeling outside of the kernel. - James -- James Morris <jmorris@namei.org> -
To counter clarify:
You are saying two things:
1. The policy always ensures a safe label.
2. Files can be relabeled in a reasonable and timely manner.
I have no questions about 2. It's a hack, but you've already
acknowledged that and it will work, allowing for some potential
cases where someone is overeager about getting a file-in-transition.
Regarding 1: This is a founding premise of the arguement, that
the "policy" is written correctly such that there is no case
where a file gets created with an unsafe label. Given the external
nature of the policy, and the number of attributes used within
the policy, and the overall sophistication of the policy mechanism,
how does one ...
a. know that a label is "safe"
b. know that a file will get a "safe" label
c. know that the policy is "correctly" written as required
The question is not if fixxerupperd can set things right.
The question is about the properly written policy that is
If you already have an in-kernel labeling scheme that you
trust to make the world safe until you get around to doing
the labeling externally you can argue that it's good enough.
But, to quote Cinderella's Stepmother, "I said "if"".
Casey Schaufler
casey@schaufler-ca.com
-
There are only about 850 file type_transition rules in the policy shipped with RHEL and the vast majority of them are templated so this isn't as hard as you think. Most are things like: type_transition ftpd_t tmp_t : file ftpd_tmp_t; which 1) don't require relabeling to something else and 2) very easy to audit. A quick look suggests that the potentially less-restrictive label is never chosen, for example you'll see: type_transition groupadd_t etc_t : file shadow_t; type_transition useradd_t etc_t : file shadow_t; Instead of the default transition being etc_t they are labeled as shadow_t (more restrictive) and then potentially relabled to etc_t. That said, the lack of a type_transition in this case is as important as having one if the default type (the parent directory) is less restrictive. We already have tools that analyze policy and even tools to warn about potential errors in policy (apol and sechecker). It might be a good idea to add some more analysis to these tools to point out potential labeling errors that can be used in automatic analysis, which Several systems have gone off to ct&e and none of them use restorecond. These are custom build systems and relabeling is kept to a minimum and the applications are architected in a way that precludes this being The "if" for SELinux is alot easier than you suggest. It certainly outweighs the disadvantages of the path based scheme IMHO. -
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
Can the daemon using inotify access to all pathnames in all process's namespaces? Are the namespace the daemon has and the namespace of pathnames notified via inotify always the same? -
If they are in the same namespace, then yes, they will as far as I can tell. Do you think this is incorrect? thanks, greg k-h -
At least, I think SELinux's "make relabel" can't relabel files that are not in the namespace of "make" process. I don't know how to use inotify, but what I worried is ... If there are cases they are in different namespace, it is impossible to relabel using userland daemon (i.e. deferred-relabeling won't work) unless all pathnames of all namespaces are somehow accessible via inotify. Thanks. -
In our 1995 B1 evaluation of Trusted Irix we were told in no uncertain terms that such a solution was not acceptable under the TCSEC requirements. Detection and relabel on an unlocked object creates an obvious window for exploitation. We were told that such a scheme would be considered a design flaw. I understand that some of the Common Criteria labs are less aggressive regarding chasing down these issues than the NCSC teams were. It might not prevent an evaluation from completing today. It is still hard to explain why it's ok to have a file that's labeled incorrectly _even briefly_. It is the systems job to ensure that that does not happen. Casey Schaufler casey@schaufler-ca.com -
Um, Casey, he is talking about how to emulate AppArmor behavior on a label-based system like SELinux, not meeting B1 or LSPP or anything like that (which AppArmor can't do regardless). As far as general issue goes, if your policy is configured such that the new file gets the most restrictive label possible at creation time and then the daemon relabels it to a less restrictive label if appropriate, then there is no actual window of exposure. Also, there is such a daemon, restorecond, in SELinux (policycoreutils) although we avoid relying on it for anything security-critical naturally. And one could introduce the named type transition concept that has been discussed in this thread without much difficulty to selinux. -- Stephen Smalley National Security Agency -
Yes. What I'm saying (or trying to) is that such an implementation We're not talking about an implementation based on AppArmor. As you point out, we're talking about implementing name based access Is it general practice to configure policy such that "the new file gets the most restrictive label possible at creation time"? I confess that my understanding of the current practice in policy generation is based Yup, I see that once you accept the notion that it is OK for a file to be misslabeled for a bit and that having a fixxerupperd is sufficient it all falls out. My point is that there is a segment of the security community that had not found this acceptable, even under the conditions outlined. If it meets your needs, I say run with it. Casey Schaufler casey@schaufler-ca.com -
We're talking about emulating pathname-based security on SELinux. Pathname-based security is inherently non-tranquil (names can change at any time) and ambiguous (a single name may refer to different objects in different namespaces, multiple names may refer to the same object in a single namespace), and thus cannot possibly meet information flow / classical confinement requirements. So using restorecond as the basis for such an emulation loses nothing from what you already had. Using restorecond as the fundamental basis for the security of SELinux itself Understand that we view it as a method of last resort, only to be considered after trying first to: 1) Configure policy transparently to label the file correctly at creation time (based on the creating process' label, the parent directory label, and the kind of file), or if that fails, 2) Modify the library or application code to label the file correctly at creation time (e.g. when multiple files that should be protected differently are created by the same process in the same directory, I think you misunderstand what I mean by named type transition here - that is a reference to earlier discussions in this thread on extending the SELinux type_transition statements to let the kernel directly label new files based not only on creating process and parent directory label but also the last component name. With such an extension, SELinux could directly distinguish e.g. /etc/shadow from /etc/passwd at file creation time in the kernel without needing anything like restorecond in userspace. There is no temporary mislabeling with such a mechanism. -- Stephen Smalley National Security Agency -
If that segment feels that way, then I imagine AA would not meet their requirements today due to file handles and other ways of passing around open files, right? So, would SELinux today (without this AA-like daemon) fit the requirements of this segment? thanks, greg k-h -
Yes - RHEL 5 is going through CC evaluations for LSPP, CAPP, and RBAC using the features of SELinux where appropriate. Karl -
Great, but is there the requirement in the CC stuff such that this type of "delayed re-label" that an AA-like daemon would need to do cause that model to not be able to be certified like your SELinux implementation is? As I'm guessing the default "label" for things like this already work properly for SELinux, I figure we should be safe, but I don't know those requirements at all. thanks, greg k-h -
There are two things: 1) relabeling (non-tranquility) is very problematic in general because revocation is hard (and non-solved in Linux). So you would have to address concerns about that. 2) Whether this would pass certification depends on a lot of factors (like the specific requirements - CC is just a process not a single set of requirements). I don't know enough to really guess. More to the point, though, the requirements in those documents are Probably not - you would likely want it to be a label that can't be read or written by anything, only relabeled by the daemon. Karl -
I think we need to distinguish between relying on restorecond-like mechanisms for the security of SELinux vs. relying on them for emulating pathname-based security. The former would be a problem. The latter is no worse than pathname-based security already, because pathname-based security is inherently ambiguous and non-tranquil, and revocation isn't -- Stephen Smalley National Security Agency -
Emulation using lazy relabeling introduces a window where the files have the wrong label. In those windows, the pathname based policy is being violated, and unintended side effects are suddenly possible. This includes granting of access to files that applications should no longer have access to according to the pathname based policy, which would be similar to what happens when a process keeps an open file handle right now. But it also includes denial of access to files that applications should have access to, and this might cause those applications to fail. So this is where relabeling from user space is much worse. The only way to get rid of the denial of service problem would be to make the rename and relabel an atomic operation. The time this can take is huge though, so that's not acceptable. Another, less catastrophic problem is that rename has always been relatively fast and inexpensive, and I'm sure plenty of applications rely on this performance characteristic. Making rename a very expensive operation in at least some cases (which are more than theoretical) would hurt those applications, and nothing much could be done about it. Adding better new-file mechanisms to SELinux probably is a good idea, and it would weaken the SELinux seurity model for all I can tell. It doesn't address the relabeling problem though. Andreas -
That segment is itself divided (think the "Judean Peoples Front" and the "Peoples Front of Judea") on many issues, but as it has always put correctness over ease of use I would expect AppArmor to have a tough roe to hoe. There are other segments for which AppArmor may well be appealing, and those segments have always been much The JPF is head over heels in love with SELinux, restorecond and all. The PFJ has some issues, but will most likely go along with the JPF in part because the JPF is bringing the beer and besides, what are their alternatives today? The PJF ("that's him, over there") is still stunned by some of what SELinux accepts as normal (restorecond, 400,000 line "policy" definitions with embedded wildcards) and spends a lot of time chanting the TCB Principle in hopes that it will help, but no lightning strikes from above to date. But you knew that. I'm an advocate of making a variety of alternates available which is why I had originally proposed the authoritative hooks version of the LSM and why I don't believe in rolling every possible security facility into SELinux. I also believe in warning people of pitfalls before they've impaled themselves on the spikes, but some people gotta have the experience. Just trying to help. Casey Schaufler casey@schaufler-ca.com -
Greg, to implement the AA approach useing SELinux you need to have a way that files that are renamed or created get tagged with the right label automaticaly with no possible race condition. If this can be done then it _may_ be possible to do the job that AA is aimed at with SELinux, but the work nessasary to figure out what lables are needed on what file would still make it a non-trivial task. as I understand it SELinux puts one label on each file, so if you have three files accessed by two programs such that program A accesses files X Y program B accesses files Y Z then files X Y and Z all need seperate labels with the policy stateing that program A need to access labels X, Y and program B needs to access files Y Z extended out this can come close to giving each file it's own label. AA essentially does this and calls the label the path and computes it at runtime instead of storing it somewhere. David Lang -
Hello. I tried to give each file it's own label, but I couldn't do it. http://sourceforge.jp/projects/tomoyo/document/nsf2003-en.pdf There are many elements that forms too strong barrier between pathname and labels, such as bind-mounts, hard links, newly created files, renamed files, temporary files and so on. So I gave up giving each file a label that can be used as an identifier, and took an approach to forbid unneeded mount operations, unneeded link operations, unneeded renaming operations to keep the pathname represent it's own identifier as much as possible. Thanks. -
On Sat, 9 Jun 2007 11:01:41 +0900 is trying to implement, is to do in one step what SELinux does in two steps; that is trying to combine labelling and enforcement into a single step. If this is so, then why can't it just feed its automatic That paper seems entirely focused on the automatic generation of policy, and doesn't seem to help the discussion along. For instance, there may be a way to implement AA on top of SELinux _without_ giving each and AA must have a function that decides the security rights for any given path in order to make its enforcement decisions. It must surely be able to deal with all those things you listed above (bind-mounts,hard links etc). So why can't those decisions be turned into labels that are fed into SELinux enforcement code? Sean. -
with AA hardlinks are effectivly different labels on the same file one of the big problems with SELinux is what label to put on new files (including temp files), the AA approach avoids this (frequent) problem entirely. In exchange AA picks up the (infrequent) problems of bind-mounts and hard-link creation. People have tried to equate these prolems to show that AA has just as many problems as SELinux, but you can run systems for decades without creating hard-links or bind-mounts also you seriously misunderstand the AA approach AA does NOT try to create a security policy for every file on the system. Instead AA policies are based on specific programs, and each policy states what files that program is allowed to access. if you are useing AA to secure all exposed services on a box you don't have to try to write a policy to describe what gcc is allowed to access (unless through policy you give one of your exposed services permission to run gcc, and even then I'm not sure if gcc would inherit restrictions from it's parent or just use it's own) the resulting policy is much easier to understand (and therefor check) becouse it is orders of magnatude smaller then any comprehensive SELinux policy. the AA policy is also much easier to understand becouse you can look at it in pieces, understand that piece, and then forget it and move on to the next piece. for example, if you write a policy for apache that limits it's access to it's log files, install directories, and document root. then you write a policy for your log analysis tool to access it's libraries, report directories (under the apache document root) and the apache log files (read only), these two policies are independant, you don't have to think about one while creating the other (which you would have to do if you had to put one label on apache binaries, another on normal web documents, a third on the reports, a fourth on the log files, and a fifth on the binaries for the log analysis tool. and ...
On Fri, 8 Jun 2007 21:56:06 -0700 (PDT) So what? SELinux can be be altered to accept whatever label you generate. You are thinking about the way SELinux operates today, not how it might operate to accommodate AA inclusion in the kernel. Instead of SELinux always obtaining labels from file attributes, it could ask AA for them please read a bit more carefully, I was responding to someone else who Nobody is asking you to change the AA policy file. It lives in user space. But i fail to see the problem in translating it into SELinux terms for Again, try to think outside the box a bit. This isn't about using SELinux as it exists today. But imagine an SELinux that would ask you to supply a security label for each file _instead_ of looking up that label itself. Wouldn't that let you implement everything you wanted while still And so it could remain; this is about implementation, not model. Sean -
so are you suggesting that SELinux would call out to userspace for every file open to get the label for that file? just off the top of my head what would all these kernel->userspace->kernel transitions do to performance? would SELinux give userspace the full path to that file? if so wouldn't it have to implement most of what AA adds to do this? if not how would userspace figure out what label to hand back without this info? how would SELinux figure out the permissions for the userspace Daemon? how would you change both the rules for labels in the kernel and the yes, you could add all the AA code to SELinux and then say that the result is implemented in SELinux, you may even save a little bit of code in some parts of it (but I would argue that you add more code in others, say for the userpace interface and userspace labeling code), but the result wouldn't be in the spirit of SELinux. it may be possible to write something that resembles AA in SELinux policy (once you solve the problem of how to label newly created files securely), but it's also possible to write a webserver in COBOL to run out of inetd, that doesn't mean that it makes any sort of sense to do either one. on the other hand, it may be a good idea. let's see how people really use AA once they have it available and the SELinux folks can work on duplicating the functionality, if they do then the existing AA interface could be phased out over time, or the internal implementation could change. but arguing that SELinux _may_ be able to do the job of AA _someday_ should not prevent AA from being included today (especially when so many of the SELinux developers are so opposed to the very concept of AA, which doesn't indicate that they are about to rush out and implement the pieces needed to make it work) David Lang -
On Fri, 8 Jun 2007 22:38:57 -0700 (PDT) No, i'm not. You must already have a kernel function in the current implementation of AA that decides the proper policy for each path. Why not use it to feed labels into SELinux. Sean -
if it was this easy just have SELinux set the label == path you first need to figure out what the path is. right now this can't be done, the AA paches provide this capability. second, the AA policies aren't based just on the path, they are based on the program accessing the path, then the path. you can have two different policies for two different programs accessing the same path, but for most programs (although, not nessasarily most activity) there will be no policy, and therefor no need to check the path. but even if you did these things, why would it be an advantage to use a mechanism to create a dummy label and pass it off to different code rather then just decideing at that point? once the AA code knows what the policy for this path is for this program (which it would need to know to set the label) how is it a win to pass this off to another chunk of code? you would also need to make sure that the SELinux code didn't try to cache the label for future use either, becouse in the future the access may be from another program and so the policy that's needed is different. David Lang -
On Sat, 9 Jun 2007 00:04:15 -0700 (PDT) The question is: why not just extend SELinux to include AA functionality rather than doing a whole new subsystem. What exactly about AA demands an entire new infrastructure rather than just building on what already It seems the main purported advantage of AA is it doesn't require maintaining labels on files etc. In fact, that's the only conceptual difference I can see other than a simpler policy file format. So why not just make an AA extension to SELinux that implements this main difference (ie. create labels on the fly). Then have a userspace program that converts the pretty-peace-and-love AA policy file format into the baby-killing SELinux format and feed it into the kernel. All of a sudden you've implemented the main features of AA with very few changes to the kernel. It should be more maintainable, and much Because it requires you to reimplement much of what is already in the kernel. It requires you to be able to understand an entire new policy mechanism Again you're only looking at the way the AA code is _today_. If it were refactored to be an extension of SELinux, there would be no reason for the AA kernel code to know any policy whatsoever. All it would need to know is a path-to-label mapping. SELinux would then enforce the AA policy that it received from your userspace tool that translates your native It's a win because the policy enforcement code is already in the kernel. All you have to do is extend SELinux to create labels on the fly and provide a userspace tool to convert the nice AA policy files into something SELinux You seem to be quibbling over small little unimportant details and refusing to part with your current implementation. It would seem the easiest way to get the functionality you want into the kernel is to be a bit more flexible on implementation. Sean -
Do you agree with passing "struct vfsmount" to VFS helper functions and LSM hooks and introducing d_namespace_path() so that the AA extension can calculate the requested pathname and map the requested pathname to SELinux's labels? -
On Sat, 9 Jun 2007 20:26:57 +0900 Frankly i'm not in a position to judge, but if that's the best way to provide the desired functionality, then it sounds good. But please make sure you bounce this all off someone who actually knows what they're talking about. ;o) Really I was just casually following along this ongoing conversation and had a more conceptual/design question about how things were implemented. A few people explained how AA labelling at "runtime" wasn't conceptually very different than what SELinux did. All that begged the question as to why that functionality couldn't just be tacked on to SELinux? Sean -
Sean, since you aren't in a position to judge what's acceptable and I'm not in a position to change code our exchange is pointless. I apologize to the list for the excessive messasges. David Lang -
Because, as hard as it seems for some people to believe, not everyone wants Type Enforcement. SELinux is a fine implementation of type enforcement, but if you don't want what it does it would be silly to require that it be used in order to accomplish something else, like name based access control. If the same things made everyone feel "secure" there would be no optional security facilities (audit, cryptfs, /dev/random, ACLs). It appears that the AA folks are sufficiently unimpressed with SELinux they want to do something different. I understand that there is a contingent that believes security == SELinux. There are also people who believe security == cryptography or security == virus scanners. I'm happy that they have found what works for them. Also, "just extend" implies that it would be easy to do. I suggest you go read the SELinux MLS code, and go read some of the discussions about getting MLS working for the RedHat LSP before you go throwing "just" around. Casey Schaufler casey@schaufler-ca.com -
Actually, no. AA was started at time when SELinux was very different from today, and now AA people have installed base of 'happy users' they are trying to support. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -
becouse the SELinux people don't want to have this in their code for one thing. you seem to be ignoring the SELinux people who say that pathnames are fundamentally different from labels, labels stay with the data if the file is renamed, path names do not. multiple hard-links to the same file will always have the same label for SELinux, but could have very different permissions with AA labels are part of policy, policy is not supposed to be decided by the kernel. SELinux treats all files with the same label the same. to have the same ability to treat every file differntly that AA has SELinux would have to how will you know how many labels you need to put into your policy that you load into the kernel? how will the kernel figure out what label to use for a file and the userspace code that converts the policy needs to know the names when it feeds the policy into the kernel. and you still need to implement the new LSM hooks that AA is asking for to the policy mechanism is supposed to be the LSM hooks, and AA is trying to after you change SELinux to be able to do everything that AA does then you first off, and for the record, it's not _my_ implementation. I have nothing to do with writing AA. I am just someone who manages hundreds of servers for which AA would be a good fit. In the past I've gone to a lot of effort to get less security then AA would provide to implement seperate services in seperate chroot sandboxes. I'm looking for easier and better options, I've looked at SELinux and don't believe that I can produce a reasonable policy in a reasonable amount of time (and I don't trust distro vendors to do it for me, they have to allow a lot of things that don't make sense on my systems, and I occasionally need to allow something that wouldn't make sense in the general case, let alone all the software I run that the disto doesn't know anything about) chroot sandboxes, virtual machines, containers all have the problem that when you ...
On Sat, 9 Jun 2007 01:03:15 -0700 (PDT) Tuff nuggies to the SELinux people.. Show them code good enough they'd be Not sure why you're rehashing this. We all know that not everyone agrees with AA. The point is users should have a choice.. choice is good. But that's not a justification for bloating the kernel with a bunch of code that isn't needed and can be refactored into a I'm not convinced in practice you really need a unique label for every file. Large swathes of the system would have a shared label etc.. So let's not get caught up on theoretical arguments that don't really play in practice. Has anyone on the AA team actually _tried_ to extend The AA extension will have a path-to-label mapping. Conceptually that's exactly what its doing now. Look at the arguments by AA proponents that the only difference between the AA method and SELinux is _when_ those labels are created... Sorry i don't have a link handy, but i can dig one Who says that's what is "supposed" to be in all situations? It makes more BS. All we're talking about is an extension that allows SELinux to generate labels on the fly. That goes most the way towards giving you all the functionality you're after and should be a much smaller patch Whoa. Again you're mistaking the current state of SELinux, rather than SELinux + AA extension. If such a beast provides the same features you But "working implementation" is _not_ the criteria for acceptance into Because i'm not the one trying to get something into the kernel. I'm not the one who has to show that my patches are reasonable and make best use of the current kernel infrastructure possible. Sean -
Actually, SELinux people 'liked' the concept -- they are willing to extend SELinux to handle new files better. And not only SELinux people It was something like 'is there description of AA security model? We'd like to take a look if we can do that within SELinux'. I tried to forward them pdf, but it was more AA implementation description (not AA model description) so it was probably not helpful. So yes, SELinux people want to help. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -
Yes, and in the process, AA stores compiled regular expressions in kernel. Ouch. I'll take "each file it's own label" over _that_ any time. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -
and if each file has it's own label you are going to need regex or similar to deal with them as well. David Lang -
But you have that regex in _user_ space, in a place where policy is loaded into kernel. AA has regex parser in _kernel_ space, which is very wrong. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -
That regex parser only applies user defined policy. The logical
connection between your two points doesn't exist.
Regards,
Lars
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
-
then the kernel is going to have to call out to userspace every time a file is created or renamed and the policy is going to be enforced incorrectly until userspace finished labeling/relabeling whatever is moved. building this sort of race condigion for security into the kernel see Linus' rants about why it's not automaticaly the best thing to move functionality into userspace. remember that the files covered by an AA policy can change as files are renamed. this isn't the case with SELinux so it doesn't have this sort of problem. David Lang -
How about using the inotify interface on / to watch for file changes and updating the SELinux policies on the fly. This could be done from a userspace daemon and should require minimal SELinux changes. The only possible problems I can see are the (hopefully) small gap between the file change and updating the policy and the performance problems of watching the whole system for changes. Just my $0.02. Jack -
as was mentioned by someone else, if you rename a directory this can result in millions of files that need to be relabeled (or otherwise have the policy changed for them) that can take a significant amount of time to do. David Lang -
So? The number of "real-world" times that this happens is probably non-existant on a "production" server. And if you are doing this on a developer machine, then yes, there might be some slow-down, but no more than is currently happening with tools like Beagle that people are already shipping and supporting in "enterprise" solutions. thanks, greg k-h -
Now that you're going to have to explain. Nothing like that on any of the MLS systems I'm familiar with, and I think that I know just about all of them. Casey Schaufler casey@schaufler-ca.com -
I suspect that David meant that if you were using "unique label per file" as an implementation technique to implement AA on top of SELinux, that you would then need a regexp to discern labels. It's hard to recall with all the noise, but at this point in the thread the discussion is about the best way to implement AA. Some have alleged that AA layered on top of SELinux is the best way. I think that is clearly wrong; AA layered on top of SELinux is possible, but would require a bunch of enhancements to SELinux first, and the result would be more complex than the proposed AA patch and have weaker functionality and performance. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oftc.net/#apparmor -
exactly. say that we give each file a unique label, and for simplicity we set the label == path (note that this raises the issue, what will SELinux do when there are multiple paths to the same file) now say that you want to grant apache access to all files that have labels that follow the pattern '/home/*/http/* ? you are either going to use regex matching, or you are going to have to enumerate every label that matches this (potentially a very large list). and if you try to generate the enumerated list you need to add a label to the list if a file is renamed or created to match the pattern, and delete AA as-is needs to figure out how to deal with bind-mounts, and how to handle hardlink creation in a more ganular manner (and potentially other resources like network sockets), but it's useful now even without these improvements AA over SELinux would need for SELinux to figure out how to handle file creation, file renames, and multiple paths for the same file (hard-links and bind-mounts). In addition a userspace daemon would have to be written to re-label files and/or change policy on the fly as files are renamed. the result would still have race conditions due to the need to re-label large numbers of files ACPI should have taught everyone that sometimes putting an interpreter in the kernel really is the best option. looking at the problems of bouncing back out to userspace for file creation and renames it looks like a regex in the kernel is a lot safer and more reliable. David Lang -
On Sun, 10 Jun 2007 23:45:16 -0700 (PDT) If AA requires regex matching in the kernel, perhaps it really isn't appropriate for inclusion. Surely there has to be a better way than WRONG. The labels would be obtained from AA as needed, never recorded in the file attributes. This would change nothing about what AA needed There hasn't yet been shown a requirement for a userspace daemon to implement AA over SeLinux. Sean -
Ok, you are proposing throwing out all the label handling that SELinux does, including any caching. forgive me if I agree with the SELinux people I thought the userspace component was what you were proposing instead of doing the regex matching in the kernel. if this isn't it what exactly are you proposing? you don't want the regex matching in the kernel. you don't want a userspace component to do the regex matching when files are created or renamed. how exactly do you propose to figure out what should happen to a file when it is created or it (or a parent directory) is renamed? AA policies are defined in terms of regex expressions. you say that this should be able to be done on top of SELinux somehow without changing the policies. so somewhere, something needs to interpret the regex to see if it matches the path. this needs to be either kernel code or userspace code. you have ruled out kernel code and are now claiming that userspace isn't needed. David Lang -
On Mon, 11 Jun 2007 02:33:30 -0700 (PDT) Well presumably AA would be doing caching etc.. so that doesn't seem like a problem. The SELinux people seem to think that accepting AA into the kernel and supporting path based security at all is a mistake. I guess No.. i've said quite a few times now that i'm not talking about calling out to userspace. The entire discussion of regex matching is a completely separate discussion. It's either the right thing to do, or not. But the same issues in regard to regex matching apply whether AA is built on top For whatever it's worth, i'll repeat again. The AA kernel extension would be associating paths with labels (using regex, or not). At that point all policy decisions would be enforced by SELinux using standard SELinux policy rules. The SELinux policy would be a translated version of the AA policy file. The translation could of course happen in userland. The net affect of all that... is that you get a version of SELinux which can be configured with the user friendly AA policy file format. And, files won't need to carry around security labels with them. I leave the debate about whether that's a good idea in general to others. But from what i can tell, it's the only significant difference between SELinux and AA. Depending on the way it was implemented, its conceivable that users could mix and match native SELinux policy with custom AA policies as they saw fit. Sean -
What do ACPI and AA have in common? * they both start with A * there are both nightmare * they both put interpretter into kernel Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -
the way I would describe the difference betwen AA and SELinux is: SELinux is like a default allow IPS system, you have to describe EVERYTHING to the system so that it knows what to allow and what to stop. AA is like a default deny firewall, you describe what you want to happen, and it blocks everything else without you even having to realize that it's there. now I know that this isn't a perfect analyogy, that SELinux doesn't allow something to happen unless it's been told to let it, but in terms of complexity and the amount of work to configure things I think the analogy is close. the fact that the SELinux policy _will_ affect the entire systems means one of two things. 1. you have a policy that exactly describes how every part of the system operates or 2. you have a policy that's exessivly permissive in some parts of the system becouse 'that works' and you either don't understand that part of the system well enough, or don't have time to write a more complete policy. I would argue that with the number of files on a system nowdays (483,000 on my 'minimalistic' gentoo server, 442,000 on my slackware laptop, 800,000 on a ubuntu server at work) it's not possible to do #1, so any deployed policy (especially one done by a disto that needs to work for all it's users) is going to follow #2, frequently to the point where it's not really adding much security. David Lang -
On Fri, 8 Jun 2007 22:18:40 -0700 (PDT) It must be drop dead simple to modify SELinux to be default-deny. That seems like it could be done in a small patch instead of requiring a huge new infrastructure. Let's assume that everyone agrees that AA is a good idea. Which parts of it absolutely can't be implemented in terms of SELinux? SELinux isn't fixed in stone, it can be altered if necessary to accommodate AA (as in the example above of becoming default-deny). Sean. -
what SELinux cannot do is figure out what label to assign a new file. but the bigger problem in changing SELinux to behave like AA is that the SELinux people disagree with the concept of AA. they don't believe that it's secure, so why would they add useless bloat that would only complicate their code and make systems less secure? I don't happen to agree with their opinion of AA obviously, but they have the right to their opinion, and it is their code. why should they be asked to implement and support something they disagree with so fundamentally? remember that the security hooks in the kernel are not SELinux API's, they are the Loadable Security Model API. What the AA people are asking for is for the LSM API to be modified enough to let their code run (after that (and working in parallel) they will work on getting the rest of their code approved for the kernel, but the LSM hooks are the most critical) David Lang -
On Sat, 9 Jun 2007 00:13:22 -0700 (PDT) It was a rather poor analogy i'm afraid. But the point i make still stands. So far you've failed to show any reason SELinux can't be reasonably extended So now you're claiming the real reason to let AA into the kernel is politics? Just show that the feature can be easily added to SELinux and made as an option for the end user to choose and it should go a long way to silencing Remember that the SELinux API's essentially belong to everyone under the GPL. So its not an excuse for falling into NIH syndrome and putting a bunch of new stuff into the kernel that could instead be added as a small extension to what already exists. Sean -
but the SELinux API's are not the core security API's in Linux, the LSM API's are. and AA is useing the LSM API's (extending them where they and SELinux don't do what's needed) David Lang -
On Sat, 9 Jun 2007 01:06:09 -0700 (PDT) Calling LSM "core" and pretending that SELinux can't do 90% of what you want doesn't change the facts on the ground. Clinging to the current AA implementation instead of honestly considering reasonable alternatives does not inspire confidence or teamwork. Sean. -
What you imply is pretty insulting. I can assure you we looked into many possible implementation choices, and we considered a fair number of alternatives. Have you seen the ``AppArmor FAQ'' thread? Andreas -
On Sat, 9 Jun 2007 17:17:57 +0200 Sorry for any unintended insult. The comment was meant solely for the person with whom i was talking who seemed only to be cheerleading for inclusion in current form without being willing or able to discuss alternative implementations. Sean. -
Nit: SELinux figures out what to label new files fine, just not based on the name. This works in most cases, eg., when user_t creates a file in /tmp it becomes user_tmp_t, incidentally this is something that AA cannot handle, if the filenames aren't normalized (they normally aren't). For example, my ssh agent socket is stored in /tmp/ssh-XXXXXXXX, where the X's are random characters, AA can't differentiate admin ssh agents from unprivileged user ssh agents, showing a serious flaw in their model. The complaint is that name-based labeling doesn't currently exist (and as Sean has stated that doesn't mean it _can't_ exist, just that it doesn't currently). In practice this has not been as big of an issue as you are making it out to be. Granted restorecond has a tiny race, and I wouldn't recommend using it on very security sensitive files but for usability having it relabel user_home_t to user_http_content_t isn't a problem (and causes no security issues). -
WRONG. You clearly don't understand SELinux at all. Try booting in enforcing mode with an empty policy file (well, not quite empty, there are a few mandatory labels you have to create before it's a valid policy file). /sbin/init will load the initial policy, attempt to re-exec() itself... and promptly grind to a halt. End-of-story. Typical "targetted" policies leave all user logins as unrestricted, adding security for daemons but not getting in the way of users who would otherwise turn SELinux off. On the other hand, a targeted policy has a "trusted" type for user logins which is explicitly allowed access to everything. That said, if you actually want your system to *work* with any default-deny policy then you have to describe EVERYTHING anyways. How exactly do you expect AppArmor to "work" if you don't allow users to run "/bin/passwd", for example. Cheers, Kyle Moffett -
sigh, two paragraphs below what you quoted I acknowledged exactly what you state. however since you must tag everything before you turn on any security it seems to me that you have to define everything, which is a Ok, it sounds as if I did misunderstand SELinux. I thought that by labeling the individual files you couldn't do the 'only restrict apache' for AA you don't try to define permissions for every executable, and ones that you don't define policy are unrestricted. so as I understand this with SELinux you will have lots of labels around your system (more as you lock down the system more) you need to define policy so that your unrestricted users must have access to every label, and every time you create a new label you need to go back to all your policies to see if the new label needs to be allowed from that policy is this correct? David Lang -
Actually, it's easier than that. There are type attributes which may be assigned to an arbitrary set of types, and each "type" field in an access rule may use either a type or an attribute. So you don't actually need to modify existing rules when adding new types, you just add the appropriate existing attributes to your new type. For example, you could set up a "logfile" attribute which allows logrotate to archive old versions and allows audit-admin users to modify/delete them, then whenever you need to add a new logfile you just declare the "my_foo_log_t" type to have the "logfile" attribute. On the other hand, I seem to recall that typical "targeted" policies don't grant most of the additional access via access rules, they instead add a special case to the fundamental "constraints" in the policy (IE: If the subject type has the "trusted" attribute then skip some of the other type-based checks). Cheers, Kyle Moffett -
isn't this just the flip side of the same problem? every time you define a new attribute you need to go through all the files and decide if the new attribute needs to be given to that file. -
No you don't, you can add attributes to a type after-the-fact. In concept this problem is very similar to programming: You have various documented interfaces used by different policy files to interact with each other. As long as your policy files conform to the documented interfaces then you *DONT* have to manually inspect each file because you can make basic assumptions. On the other hand, when you break that interface "contract" you will get very unexpected results. For the above example: My syslog policy file would create a "logfile" attribute and types for "/var/log/auth/auth.log", "/var/log/kern/kern.log", and "/var/log/ messages". It would also create a "logdaemon" attribute which has automatic type transitions to create files in different "/var/log/*" directories Finally, it would allow the syslogd type to create and append to its specific file types for "auth.log", "kern.log", and "messages". My logrotate policy file would depend on the syslog policy and would declare the logrotate daemon type as a "logdaemon", and additionally allow logrotate to read, rename, append, and delete "logfile" types. Since logrotate is a "logdaemon", it already has the appropriate type transitions for new types. My samba policy file would depend on the syslog policy and would declare the samba daemon type as a "logdaemon" and the "/var/log/ samba/*" type as a "logfile". Then it would add a type transition rule so when "logdaemon" creates new files in "samba_log_dir_t", they have the appropriate "samba_log_t" label. Finally, samba would allow itself to append to "samba_log_t" files. Note that now when "logrotate" runs and rotates files in /var/log/ samba, it will automatically create the new files with type "samba_log_t", even though there are no *direct* associations between those types. If the syslog policy file was poorly written it could seriously adversely affect the security of the system, but hopefully that's ...
if you have your policy figured out and then go and apply it to applications then you are correct. I'm talking about the situation where you start off by defining a policy for Samba, and then afterwords decide that you want to have seperate "logfile" and "logdaemon" type then you would need to go back and re-examine all the files to tell what needs to be labeled as what. if you can do all the policy design in advance (and get it right) then SELinux is a great solution. if you don't have that time and have to do the policy incrementaly you will end up revisiting and revising your I _am_ a security professional. I've been doing security sysadmin work on Linux for over a decade now. From your description I'm exactly the type of person you are saying should be figuring this out. So please back off of the 'this is hard, you should leave it to the professionals' line a little bit ;-) if the AA policies can be compiled into SELinux policies that would work (currently they can't and many SELinux people oppose the features that would need to be added to make it possible) but the compile process leaves room for more bugs in an areas that's going to be hard to investigate. (This isn't a fault of SELinux, it's a common issue with compilers, the compiled 'thing' is designed to be machine friendly, not user friendly. it doesn't matte if it's compiling C into machine code or high-level firewall rules into iptables commands or AA policies into SELinux labels and policies). adding a complex intermediate layer does not nessasarily add security, but it definantly adds complication. once SELinux has a way for a trusted user to edit a security sensitive file (via the process of creating a file and renameing it into place) without needing SELinux aware tools and have the result accepted as valid by the rest of the system then it becomes possible to implement an AA to SELinux policy compiler, but saying that AA should not be accepted becouse it's possible to modify ...
That's not quite right:
* SELinux Strict Policy is a default-deny system: it specifies
everything that is permitted system wide, and all else is denied.
* AA and the SELinux Targeted Policy are hybrid systems:
o default-deny within a policy or profile: confined processes
are only permitted to do what the policy says, and all else
is denied.
o default-allow system wide: unconfined processes are allowed
to do anything that classic DAC permissions allow.
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/
Director of Software Engineering http://novell.com
AppArmor Chat: irc.oftc.net/#apparmor
-
Still not completely correct, though the targeted policy has an unconfined domain (unconfined_t) the policy still has allow rules for everything unconfined can do, 2 examples of things unconfined still can't do (because they aren't allowed by the targeted policy) is execmem and a while back when there was a /proc exploit that required setattr on /proc/self/environ; unconfined_t wasn't able to do that either (and therefore the exploit didn't work on a targeted system). That said, the differentiation between strict and targeted is going away soon so that one can have some users be unconfined (but still with a few restrictions) and others can be fully restricted. -
