Security Enhanced Linux
What's New
Frequently Asked Questions
Background
Documents
License
Download
Participating
Mail List
Archives
Remaining Work
Contributors
Related Work
Press Releases
Information Assurance Research
NIARL In-house Research Areas
Mathematical Sciences Program
Sabbaticals
Computer & Information Sciences Research
Technology Transfer
Advanced Computing
Advanced Mathematics
Communications & Networking
Information Processing
Microelectronics
Other Technologies
Technology Fact Sheets
Publications
Related Links
|
SELinux Mailing List
subject: Multiple contexts Date: Mon, 10 Jan 2005 13:50:49 -0700
I've been trying to get the following setup working on FC3 (rawhide):
/var/www/html.userX -
virtual server for userX.mydomain labeled httpd_sys_content_t
home folder for userX, exported via Samba (not yet, but it will be, once dwalsh puts in booleans for samba reading home)
/home/userX/webserver - symlink to /var/www/html.userX Now, /var/www/html.userX needs to be accessed both by smbd and httpd. I need to label it with both samba_share_t and httpd_sys_content_t. I have to edit the cryptic m4 policy file to add a type that's accessible by both. Why is this necessary? Why can't selinux either (1) Label the file with both contexts, and permit the operation if any context permits it or (2) Create a type with the properties of both with less user interaction (without needing to modify the policy manually) Since I'm unfamiliar with how SElinux works internally, this might be a stupid question, but it seems to me that the user should not be required to understand how a policy file works to label a file for use by two restricted programs. -- Ivan Gyurdiev <ivg2@cornell.edu> Cornell University -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: Multiple contexts Date: Mon, 10 Jan 2005 23:23:12 +0000
i understand the mindset of selinux enough now to be able to say that the recommended approach would be for you to create a file type samba_share_httpd_sys_content_t and then for you to modify the selinux policy to grant the programs requiring access to those filetypes in the samba.te and the apache.te policy files.
> I have to edit the cryptic m4 policy file to add a type that's
> (1) Label the file with both contexts, and permit yes, it does seem a little curious: taking NT security descriptors (actually VMS SDs) as an example, and ignoring the fact that NT/VMS SDs contain DAC (discretionary) ACLs - each ACL is just that - an access control LIST. whereas in NT, the SD contains ACLs and the ACLs can be extended, modified and edited (and are better understood!), SElinux turns things roundabout somewhat: providing a reference (handle) into a binary policy. what i _am_ aware of is that by having the policies in a structured language, formal analysis tools can be applied to make certain guarantees and proofs. in paranoid security environments, it's far more important to be able to prove that someone _could_ break in than to not _know_ if they could break in (!) i can only hazard a hazardous guess therefore that the more "normal" ACL system [that we are used to seeing] was rejected because it makes the formal proof methodology more difficult. *shrug*. *clueless*. anyone know? l. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: Multiple contexts Date: Tue, 11 Jan 2005 01:51:33 +0000
> modified and edited (and are better understood!), SElinux turns things ... that i do not know the exact details of but i do know it [binary policy] can be edited at runtime using tools that tresys have been developing and maintaining for some time now. l. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: Multiple contexts Date: Tue, 11 Jan 2005 15:09:51 -0500
With ACLs, you have to traverse the entire filesystem state in order to:
1) determine what your policy truly is (and that policy can change
underneath you during your traversal),
Management and scalability nightmare. -- Stephen Smalley <sds@epoch.ncsc.mil> National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: Multiple contexts Date: Tue, 11 Jan 2005 21:48:18 +0000
> Management and scalability nightmare. oh - ah. yes, now it comes back to me. microsoft solved this problem partially in NT 3.5 - NT 4.0 by only reading the ACL on the file [or directory] and applying that. by the time that NT 5 [aka windeuuws teuu thousand, with NT being a trademark owned by Northern Telecom, aka Nortel and all] came around, this was considered utterly mad. recursion was added to ACLs - or "inheritance" - because to fix access to subdirectories and all contents you are required in NT 4.0 to change ALL permissions on ALL subdirectories and contents! basically you now have to traverse the directory tree right up to the mount point [as stephen says] in order to determine access rights, combining and checking permissions as you go. eeuuuw. ... was that what you were referring to stephen? l. -- -- <a href="http://lkcl.net">http://lkcl.net</a> -- -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: Multiple contexts Date: Wed, 12 Jan 2005 09:00:49 -0500
No. I'm simply referring to the fact that if your policy is encoded in the file attributes themselves, as with ACLs, then you cannot analyze the potential information flow among security equivalence classes in the system (which is necessary if you want to ensure confidentiality or integrity guarantees) without looking at all of the file attributes. Centralizing the policy allows you to analyze the potential information flow separately, and organizing the set of subjects and objects into security equivalence classes (types in TE, levels in MLS) makes the system manageable (vs. per-object policy as with ACLs). -- Stephen Smalley <sds@epoch.ncsc.mil> National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: Multiple contexts Date: Wed, 12 Jan 2005 14:44:11 +0000
> On Tue, 2005-01-11 at 16:48, Luke Kenneth Casson Leighton wrote: ... how about encoding the file attributes in the policy files, such that they are ACL-like? [i realise this is quite a radical change under-the-hood] if nothing else by having the means to apply a list of contexts [any of which may apply] to a file. the ultimate aim of which would be to make it easier for administrators to add permissions and programs without going through a complete policy rebuild / reload. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: Multiple contexts Date: Wed, 12 Jan 2005 10:00:47 -0500
I don't follow your line of thinking. The policy defines allowed interactions among security equivalence classes (types for TE, levels for MLS). A file attribute (which is merely a tag identifying the security equivalence class into which the file falls) is stored in the filesystem, associated with the inode. You don't want to move the file->type associations into the policy; you want them bound to the real objects and maintained properly at runtime.
> the ultimate aim of which would be to make it easier for This functionality can all be built on top of the existing mechanism. And we already have some incremental steps in this direction: - the conditional policy support developed by Tresys, included in the mainline SELinux, and used extensively now in Fedora, allows well-defined changes in policy based on policy boolean settings that can be manipulated from userspace and controlled at fine granularity, - the binary policy module support developed by Tresys allows policy modules to be constructed, built, and distributed without requiring a full policy source rebuild and providing proper dependency checking, - the policy daemon being developed by Tresys will allow policy management to be decomposed. See the mailing list archives if you haven't already read about it. Obviously, there is much work to do in this space, and contributors are welcome. -- Stephen Smalley <sds@epoch.ncsc.mil> National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: Multiple contexts Date: Wed, 12 Jan 2005 18:18:14 +0000
sorry. something simple: i am thinking along the lines of more than one file context being associated with a file - that sort of thing. and permission being checked and allowed on either of the contexts. in this way, someone can keep the default policy made for apache (both the .te and the .fc file) and can also create their own home-grown policy. the issue of creating a special "samba_apache_file_type_t" and deviating from two sets of standard policy files does seem... somewhat archaic. l. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: Multiple contexts Date: Wed, 12 Jan 2005 13:03:02 -0500
I already explained why you don't want that - it puts the policy into the filesystem state. -- Stephen Smalley <sds@epoch.ncsc.mil> National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: Multiple contexts Date: Wed, 12 Jan 2005 18:29:54 +0000
i don't believe it does - or i am misunderstanding. having two policy files apache.fc and mymodifiedthing.fc which _both_ have a file context for the same file / directory, such that the data that ends up in the security.selinux xattr is "apache_filetype_t, "mymodifiedthing_filetype_t" doesn't mean, in my book "policy is in filesystem state". ... does it? *lost*. l. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: Multiple contexts Date: Wed, 12 Jan 2005 16:27:16 -0500
The file_contexts configuration is not part of the kernel policy. It is only used by userspace to set the contexts for files upon installation, to recheck the state of the filesystem against the initial labeling state, or to restore portions of the filesystem to the initial labeling state. If you change the SELinux module to support a list of file contexts within the security.selinux attribute, and change its policy engine to allow access if any access is allowed to any one of those contexts, then the only way to truly identify what information flow is possible in the system is by checking the current security.selinux attributes of all files in the system for such combinations and collapsing them to a single security equivalence class for analysis purposes. Think: policy says allow P1 F1:file read; allow P2 F2:file write;, policy analysis says that there is no allowed information flow from P2 to P1, but someone does a chcon -t F1,F2 foobar and now P2 can write to foobar and P1 can read from it, so information flow is now possible. If you want to control information flow throughout the system to prevent leakage of information or to protect trusted processes against being corrupted by untrustworthy input, you can't ignore the issue. -- Stephen Smalley <sds@epoch.ncsc.mil> National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: Multiple contexts Date: Wed, 12 Jan 2005 22:41:05 +0000
ah, yuk. ... so, ultimately, it would be better to have some m4-macro-based tools that do that, munging to an intermediate step (which is same as what we have now) and then munging _that_ to a binary policy file (exactly as is now). l. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: Multiple contexts Date: Thu, 13 Jan 2005 10:55:50 -0500
I don't especially care whether it is based on m4 macros, post-processed policy.conf, or even direct manipulation of the binary policy by a tool. I just don't want it in the filesystem state, which requires complete traversal of all objects to assess. Note that we have an increasing ability to directly act on binary policies. apol already supports analysis of binary policies directly. libsepol supports direct manipulation of binary policies, and is already used for boolean manipulation by several tools and for user manipulation by genpolusers. The experimental binary policy module work by Tresys is another good step in this direction (but needs more people testing and experimenting with it if it is ever going to get mainstreamed...). -- Stephen Smalley <sds@epoch.ncsc.mil> National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: Multiple contexts Date: Wed, 12 Jan 2005 23:01:48 +0000
> single security equivalence class for analysis purposes. Think: policy yep - and the policy analysis tools would need to understand the new format.
2 ) even if they did chcon -t "F1,F2" foobar, you would still expect them to be doing that as an "interim" measure whilst they were testing something _pending_ formal analysis by putting that into the policy files. ... and once they did that, i would rationally expect the analysis tools to be able to cope, to "combine" allow P1 F1:file read; allow P2 F2:file write; into some sort of pseudo-thing ... mmm... mmm... *thinks*... the analysis would need the macro-munging approach _anyway_ in order to "grok" the new syntax - an intermediate preprocessing stage that "notices" multiple-file-applications (including possibly expanding regexps!) and ending up with something like this: filetype Files_with_F1_and_F2_applied_t;
allow P1 F1:file read;
it'd be yeurk - but doable, i think. l. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: Multiple contexts Date: Thu, 13 Jan 2005 11:03:23 -0500
It isn't a format issue; it is whether the policy is self-contained within the binary policy or whether it is distributed throughout the filesystem (and more generally, the set of all object attributes).
> 1) if someone does a "chcon -t F2 foobar" all bets would be off as Non-tranquility (ability to change the label on a subject or object) is an issue, but you can bound it statically in the policy, i.e. the policy can already ensure that F1 can never be relabeled to F2 or vice versa. If the policy allows F1 to be relabeled to F2 or vice versa, then that fact will also show up in an information flow analysis of the policy, without requiring examination of filesystem state. Also, some further controls over relabeling are coming in the MLS work.
> 2 ) even if they did chcon -t "F1,F2" foobar, you would still expect If the mechanism allows it to happen at all, you can't make any guarantees without examination of the filesystem state.
> the analysis would need the macro-munging approach _anyway_ in No. The analysis tools operate on policy.conf or binary policy already; they don't care about the macros, nor should they. The raw policy.conf or binary policy tells the true story about possible information flow, and that is what we want to know. -- Stephen Smalley <sds@epoch.ncsc.mil> National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: Multiple contexts Date: Thu, 13 Jan 2005 11:44:31 -0500
> 2 ) even if they did chcon -t "F1,F2" foobar, you would still expectcombination - how do you decide whether or not you can change those settings? Simply allowing it if you can relabel any one of the types is obviously broken... -- Stephen Smalley <sds@epoch.ncsc.mil> National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: Multiple contexts Date: Thu, 13 Jan 2005 17:17:32 +0000
i thought that it would be because the "intermediate" stage would have generated a filetype called "F1,F2" which may actually only require some extensions etc. to simply add "," as an allowed character in the file types and the policy compiler. and there would therefore be in the policy.conf file lots of things like "allow F1,F2 such-and-such". i thought that the only tricky bit would be at policy compile-time to have to run through the complete list of files on the filesystem (which is done by setfiles _anyway) making a distinction between the overlap of the regexp associated with F1 and the regexp associated with F2. l. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: Multiple contexts Date: Thu, 13 Jan 2005 12:08:49 -0500
Regardless of how the logic is implemented/specified, you had originally proposed allowing access if access to any one of the types was allowed. But in the case of relabeling a file with multiple types, that logic seems flawed, e.g. I doubt you want to allow someone to relabel a file from F1,F2 to only F1 just because they have permission to relabelfrom/to F1 but lack permission to relabel F2.
> i thought that the only tricky bit would be at policy compile-time to No, you misunderstand. setfiles is not run at policy compilation time. setfiles is only run at system install time (and in fact, it isn't even run then anymore, as rpm now handles labeling upon install for us now). -- Stephen Smalley <sds@epoch.ncsc.mil> National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: Multiple contexts Date: Wed, 12 Jan 2005 19:07:58 +0000
there is of course the other scheme which achieves the same end-result, but using customised m4 macro-based programs to do it: this scheme has been raised before. namely, to have your apache.fc file and your customthing.fc file, and to "spew forth" a combined apache_customthing_filetype_t with some macro preprocessing. then your apache.fc is unmodified, it's clean, it can be verified, upgraded etc... l. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: Multiple contexts Date: Tue, 11 Jan 2005 10:18:43 -0500
Don't confuse the user interface with the mechanism. You can build the user interface you describe in (2) on top of the existing mechanism, and others are already working on higher level policy tools and languages. -- Stephen Smalley <sds@epoch.ncsc.mil> National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: Multiple contexts Date: Tue, 11 Jan 2005 15:08:15 -0500
Because then policy would be encoded in the file attributes, not in a centralized security policy. Hence, one would be unable to analyze information flow in the system based solely on the policy and would have to also analyze the complete filesystem state, and that state is much more subject to change at runtime than the policy itself (one would hope). -- Stephen Smalley <sds@epoch.ncsc.mil> National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Ivan Gyurdiev <ivg2_at_cornell.edu> subject: Re: Multiple contexts Date: Wed, 12 Jan 2005 13:11:27 -0700
> > I have to edit the cryptic m4 policy file to add a type that's Please explain this some more - Luke also seems confused about this (unless I misunderstand). I don't understand how the change from one context to multiple contexts stored per file translates into policy being encoded in the file attributes. It seems to me that this change would simply allow more accurate association of the files with the proper security data. It is still a centralized policy which decides whether to allow an action or not - it just takes into consideration multiple contexts. I am merely suggesting that when a security decision is necessary for a file, all the contexts it is labeled with are provided by the filesystem, and the security server makes a decision based on whether an access path (not sure of terminology here) exists between the subject context and any object context. Your httpd policy describes what contexts httpd has access to. Your samba policy describes what contexts smbd has access to. This information is not stored in the filesystem somewhere - it's in the binary policy. Multiple contexts will simply allow the user to more accurately specify the class of the object that you have to work with, with minimal interaction - it is fundamentally not a samba share, or httpd content, it is both, and it seems the only sane thing to do is label it with both, or something that's a mix of the two. I am interested in the easiest possible way to do this without playing with the policy. Why should I be changing the policy? I should only need to do that when I want to describe changes in security classes and relationships between them. What I want to do is simply mark data as belong to more than one existing class, without changing either one. So, it seems to me that userspace tools should provide an easy way to mark a file for contexts it belongs to, and internally selinux could still map this information to a unique sid somehow. Is this possible? I can imagine multiple contexts for processes would be useful as well, although I can't come up with examples right now... -- Ivan Gyurdiev <ivg2@cornell.edu> Cornell University -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Bennett <spb_at_gentoo.org> subject: Re: Multiple contexts Date: Wed, 12 Jan 2005 21:40:46 +0000
AIUI, the issue is something like this: With only one type per file, it's possible to look at the policy and be certain (for example) that domain1 can't affect domain2 in any way, because there are no interactions allowed between the two, and the file types they can access don't overlap. If you allow multiple contexts per file, that ability goes out of the window, and you have to look at which files have multiple contexts and what contexts they are before you can figure out where information can and can't flow. Of course I may be off here, and I may have missed more subtleties, but that's the problem I can see with multiple types per file. Someone correct me if I'm wrong here. :) -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: Multiple contexts Date: Wed, 12 Jan 2005 16:48:24 -0500
Thanks, another voice of reason... -- Stephen Smalley <sds@epoch.ncsc.mil> National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: Multiple contexts Date: Wed, 12 Jan 2005 23:07:24 +0000
and you'd need to take all of the files matched by a regexp for one filetype, and all of the files of the other, work out if there are any common ones, and those would be your "multiple contexted" files. this you could do at policy compilation time. the thing is - which is easier: to expect people to do that analysis themselves [by modifying the default policies] or to do it in an automated at-pol-compile-time? what is gained and is it worth it in terms of the cost of development and extra complexity of the policy macroing system and the useability? is the extra syntax useful or hazardously complex? l. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: Multiple contexts Date: Thu, 13 Jan 2005 11:06:27 -0500
No. As I said, file_contexts is not part of the kernel policy. It is only used by userspace tools like setfiles and restorecon to set the extended attributes upon installation to an initial labeling state (or to recheck or to restore against that initial labeling state). If the policy is self-contained (as it is currently), then you don't need to look at file_contexts or the on-disk attributes in order to determine potential information flow, although you may choose to look at them after an analysis of the policy in order to see how "real" certain flows might be with the current system state.
> the thing is - which is easier: to expect people to do that The question doesn't make sense, because the automated at-pol-compile-time analysis cannot be done if the policy is encoded in the filesystem. -- Stephen Smalley <sds@epoch.ncsc.mil> National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: Multiple contexts Date: Wed, 12 Jan 2005 16:47:41 -0500
If we followed that approach, then we wouldn't be able to tell whether information can flow from type A to type B without analyzing the filesystem state to see what files had multiple contexts and collapsing each such combination into a single security equivalence class (type).
> Your httpd policy describes what contexts httpd has access to. You can then no longer tell whether httpd and smbd (or anything that uses them) might interact without looking at the file attributes on disk, as a file might have both contexts.
> I am interested in Because by allowing access by multiple domains to a single object, you _are_ changing the policy, regardless of it is hidden or not.
> I should Allowing multiple domains that could not previously interact to do so is changing the relationship between the security classes.
> What I want to do That is a communication channel betweeh them.
> So, it seems to me that userspace tools should provide Not desirable. -- Stephen Smalley <sds@epoch.ncsc.mil> National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Ivan Gyurdiev <ivg2_at_cornell.edu> subject: Re: Multiple contexts Date: Wed, 12 Jan 2005 16:08:39 -0700
What about a tool that creates a hybrid type on demand, and stores that information in the policy? createcon samba_httpd_content_t --inherit
samba_share_t httpd_sys_content_t
There has to be an easier way to do this than changing the original policy file. The original policy file is hard to understand, and should be left alone. -- Ivan Gyurdiev <ivg2@cornell.edu> Cornell University -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: Multiple contexts Date: Thu, 13 Jan 2005 11:10:19 -0500
That would certainly be feasible. libsepol provides an interface for direct manipulation of binary policies, so you can build tools on it that directly perform any kind of transformation, and it is already used for boolean customization (init, load_policy) and regenerating the user database (genpolusers) without requiring full policy sources. The experimental binary policy modules work by Tresys is another step in this direction, you might want to experiment with it (which would also help it to mature and get it mainstreamed sooner). However, something to note is that if tools begin to directly manage the TE portion of the binary policy (vs. easily separable elements like booleans and users where we can maintain local config files that override the base settings in the shipped binary policy), then we have to have some way to deal with merging/conflicts when policy updates occur from a source rebuild. -- Stephen Smalley <sds@epoch.ncsc.mil> National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: Multiple contexts Date: Thu, 13 Jan 2005 18:37:05 +0000
> On Wed, 2005-01-12 at 18:08, Ivan Gyurdiev wrote: > > What about a tool that creates a hybrid type on demand, and stores that > > information in the policy? i believe that the same issues apply to the "hybrid" types as apply to "ACLs" - the only difference that i perceive is the letters contained in the file_contexts [whether a "," is allowed in the name of the "hybrid" type]. the only complication therefore would be that if your users expected to create a combination - a "hybrid" type not previously encountered before: that's doable though. l. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Thomas Bleher <bleher_at_informatik.uni-muenchen.de> subject: Re: Multiple contexts Date: Fri, 14 Jan 2005 00:17:49 +0100
This seems very useful. I have experimented a bit with this idea this evening; the resulting script is attached. It takes a policy.conf and outputs a new type (plus corresponding rules). The script is not perfect because it parses the policy.conf itself, but it should work for almost all file_types. You will still need policy sources, but you won't need to go through all sources to find the appropriate rules, the following should do the trick (not tested): # cd /etc/selinux/strict/src/policy # make policy.conf # createcon samba_httpd_content_t samba_share_t httpd_sys_content_t < policy.conf >> domains/misc/local.te # make reload Thomas -- http://www.cip.ifi.lmu.de/~bleher/selinux/ - my SELinux pages GPG-Fingerprint: BC4F BB16 30D6 F253 E3EA D09E C562 2BAE B2F4 ABE7From: Ivan Gyurdiev <ivg2_at_cornell.edu> subject: Re: Multiple contexts Date: Fri, 14 Jan 2005 00:07:56 -0700
> This seems very useful. I have experimented a bit with this idea this Modified to work for N>=2 parent types, and fixes a bug in regexp to match exact type, not any string containing it. Disclaimer: I don't know a thing about perl. ... However, yes, I think it would be useful to have some sort of script to do this kind of thing as part of the selinux tools. I shouldn't have to tell it where to read from and write to. -- Ivan Gyurdiev <ivg2@cornell.edu> Cornell UniversityFrom: Ivan Gyurdiev <ivg2_at_cornell.edu> subject: Re: Multiple contexts Date: Thu, 20 Jan 2005 13:52:45 -0700
Corrected regexps. New version attached. -- Ivan Gyurdiev <ivg2@cornell.edu> Cornell UniversityFrom: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: Multiple contexts Date: Wed, 12 Jan 2005 23:32:41 +0000
would you accept that that could be done at policy compile time, and that it would be unnecessary to do that at runtime? [if yes, then the question becomes a) who's gonna do the work b) is it useable without making selinux horribly complex] would you also agree that if someone wants to mess things up with chcon then all bets are off for _any_ kind of analysis? btw so you aren't thinking of doing something irrational in order to stay sane i should point out that i'm not pursuing this to be bloody-minded - hopefully you know me better than that by now! l. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: James Carter <jwcart2_at_epoch.ncsc.mil> subject: Re: Multiple contexts Date: Thu, 13 Jan 2005 08:56:41 -0500
> would you also agree that if someone wants to mess things up
Not true. Look at Steve's earlier example again.
allow P1 F1:file read;
In analyzing the policy, we don't care what files are labeled with F1 or F2, what we care about is that there is no information flow between P1 and P2. Using chcon will not change the fact that there is no information flow between P1 and P2. Now imagine that we do allow lists of file contexts. We could then go to the extreme of having a separate type for each permission and build the policy by using lists of contexts. allow P P_FR:file read; allow P P_FW:file write; allow P P_FE:file execute; allow Q Q_FR:file read; allow Q Q_FW:file write; allow Q Q_FE:file execute; and so on. Now label the filesystem file1 P_FR file2 P_FR,P_FE,Q_FR,Q_FE file3 P_FR,P_FW,P_FE,Q_FR and so on. How do you analyze the system now? What can we say about the information flow between P and Q without looking at the filesystem? Do you see that the policy is now on the filesystem? Analysis of the policy statically will not tell you anything, you have to know how the filesystem is labeled to have any idea of the information flows. -- James Carter <jwcart2@epoch.ncsc.mil> National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: Multiple contexts Date: Thu, 13 Jan 2005 16:46:38 +0000
sorry i meant to qualify: any kind of analysis using just the policy files alone.
> > at some time when i woke up this morning, i had a flash of inspiration. i recognised that there was a problem with what i was proposing. it was something to do with creating new files, that not even an "intermediate" policy based off of combining and creating "intermediate" filetypes would fix, without, as you say, examining all files covered by an "intermediate" regexp. i could not, for the life of me, tell you what that is, now. ... something to do with working out what the overlaps between two regexps for file contexts, creating new regexps in a venn diagram like fashion, then applying them with setfiles... ... and yet that still doesn't help. so, yes. time to drop it :) l. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: Multiple contexts Date: Thu, 13 Jan 2005 11:16:06 -0500
No, it cannot be done at policy compile time, because the information (the combinations of types on files) is not captured in the policy. file_contexts is not authoritative and is not part of the policy, and the only authoritative source of information about the file attributes is the on-disk version. Full filesystem traversal required to do the analysis you propose. No examination of file_contexts or filesystem state required to do current analysis of potential information flow throughout the system.
> would you also agree that if someone wants to mess things up Relabeling is controlled by policy already, and finer-grained control of it is coming as part of the MLS work, so policy can bound such relabeling to avoid illegal information flow, or at least limit the ability to relabel in ways that violate information flow goals to specific trusted subjects. -- Stephen Smalley <sds@epoch.ncsc.mil> National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: Multiple contexts Date: Thu, 13 Jan 2005 16:48:28 +0000
i believed that it would be acceptable to have as part of the intermediate stage a full filesystem traversal, but as i mentioned in the reply to james, i woke up with an insight into a flaw of what i am advocating and cannot now remember what it is! sorry! l., -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: Multiple contexts Date: Thu, 13 Jan 2005 11:37:18 -0500
Having to analyze the complete filesystem state: 1) doesn't scale. Think of a site with millions of files. 2) isn't stable. Think of runtime changes occuring all the time as files are created, destroyed, relabeled, etc. In any event, I consider the topic (of multiple contexts per object) closed. -- Stephen Smalley <sds@epoch.ncsc.mil> National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: Multiple contexts Date: Thu, 13 Jan 2005 17:19:21 +0000
... setfiles?
> 2) isn't stable. Think of runtime changes occuring all the time as ack. likewise. wish i could remember what the flaw was. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: Multiple contexts Date: Thu, 13 Jan 2005 12:10:55 -0500
As I've said repeatedly, setfiles was only intended to be used to perform initial labeling upon installation, and possibly to periodically recheck/restore portions of the filesystem against the initial labeling state. Nothing else. -- Stephen Smalley <sds@epoch.ncsc.mil> National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.
|
|
Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009 |