On Fri, 2008-02-15 at 12:50 -0500, Eric Paris wrote: > So after many months of trying to avoid it Dan finally beat me into > looking at permissive domains. I'm coming to the list to ask how people > feel the transfer of knowledge that a domain is permissive between the > policy and the kernel should be implemented. (And to point out what I > think is a bug I found while trolling around the code today) > > Old discussion of permissive domains. > http://marc.info/?l=selinux&m=118953810913436&w=2 > > The basic idea is that we want a domain in which a process can run > without any permission enforcement and without flooding the audit logs. > After much discussion I think everyone agreed with (or at least stopped > arguing against) a couple of things. > > 1) do this in policy (not selinuxfs) > 2) have it act just like 'setenforce 0' > > My question today is about #1. How to implement? Karl suggested > stealing a bit from the type_datum->primary field to indicate to the > kernel that a certain type was a permissive domain. Can I do this? I > guess this is a question for the setools group. Do you make use of the > actual value stored in 'primary'? The kernel does not. Does anything > make use of the actual value outside of the tool chain? Please say 'no' > and make this easier for me. > > I want to throw away the 'primary' field all together in the final > binary policy and create a 'new' field called 'flags' in its place. > After my change flags would make use of 2 bits. > > #define F_PRIMARY 0x00000001 > #define F_PERMISSIVE 0x80000000 > if (type_datum->old_primary) > type_datum->flags = F_PRIMARY; > if (permissive domain) > type_datum->flags |= F_PERMISSIVE > > This only works if noone makes actual use of the value in ->primary. If > someone makes use of the value in primary I can't really reuse that area > on disk and I think I'm going to have to bump the policy version and add > a whole new ->flags field on disk (I don't think pmoore's capability > stuff really helps). Maybe the tools could just agree to ignore the > last bit? To be honest I'm not personally terribly concerned about > setools backwards compatibility. I'm really only thinking about > function backwards compatibility, so maybe the tools people would be ok > with me just userping a bit (but I'd much rather have a more clear > 'flags' than 'primary + one bit stolen for some other random crap). For > backwards compatibility I might have to bump the policy number even if > noone has a problem with me redefining the meaning of the ->primary > field, not sure yet haven't really wrapped my brain around it. I think > there is a kernel bug which actually makes it possible to reuse the > field in my new way and maintain backwards kernel compatibility. > > **The Bug** > In the binary policy on disk ->primary is a uint32_t but in the kernel > ->primary is an unsigned char. When we load policy we just have > > typdatum->primary = le32_to_cpu(buf[2]); > > So we are truncating to 8 bits. I think that means that if the on disk > ->primary value is greater than 0xFF but the lower 8 bits are all 0 we > are going to screw this up (maybe this is impossible, but I don't see > why looking at libsepol quickly). Thanks to this bug though I think I > could use the 32nd bit of the on disk representation on old kernels and > they wouldn't even realize it. New kernels could be made to pay > attention to that bit. Backwards compatibility through bugs, I love it. > It also means I don't really want to fix this bug right now *smile* > **End bug** Kernel policy representation only uses ->primary as a boolean flag (is it a primary name or an alias, with the type index value in ->value regardless). Modular policy introduced the notion of using it to store the primary type index for aliases (when ->flavor == TYPE_ALIAS). By the time we reach kernel policy (after expansion), it should only be a boolean again. > There are other options on how to represent permissive domains in > policy, I think someone suggested > > allow domain domain:process permissive > > which would mean 2 passes through the avc for denials (at least the > first time for every sub/obj/class triple). But this method got poo > poohd because of * and ^ usage. Do we really use * and ^ any more? I > honestly don't know. It also makes all denials a little slower, but > shouldn't be noticeable on a system with a 'proper' policy. > > What other ideas exist? I'm looking for any ingenious ideas on how we > can transfer 'this is a permissive domain' from the policy into the > kernel. What I really want is a way to do it being backwards compatible > and without bumping the policy version.... > > Please, thoughts and brilliance requested, I'll do the coding, just > point me in the direction you see brightest. Can I redefine ->primary > to be ->flags? Do I need to just make a new ->flags? Should I go > through the avc twice to see if we are a permissive domain? Is there a > better way to communicate this information from the policy into the > kernel? > > -Eric -- Stephen Smalley 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@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
