Stephen Smalley wrote: > On Fri, 2008-02-15 at 14:43 -0500, Eric Paris wrote: >> On Fri, 2008-02-15 at 13:57 -0500, Stephen Smalley wrote: >>> On Fri, 2008-02-15 at 13:35 -0500, Joshua Brindle wrote: >>>> Stephen Smalley wrote: >>>>> 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. >> >> I guess this being done in src/expand.c::type_copy_callback(). >> >> All my thought is for nothing though. Somehow in the language we >> have to represent permissive domains. That in and of itself >> requires a version bump doesn't it? Drat. >> >> So what format do we want to go with? >> >> permissive httpd_t; >> >> anyone got anything better? >> >> So with the policy version bump should I add a new field, ->flags to >> the on disk type_datum represenation? Should I instead just rename >> ->primary to ->flags and teach libsepol to mask off the flag? I >> don't know the toolchain well enough to know if we ever write more >> than a boolean to disk in ->primary. Guess that's what I'll look >> for now but first glance tells me I might as well use another 32 >> bits on disk since it seems as though we have such disperate usage >> of primary for POLICY_KERNEL vs everything else. > > Crazy idea: Make "permissive" a special type attribute name, > and mark types that should be permissive with that attribute > via typeattribute. > Then let the usual type attribute handling propagate it throughout. > Aaahhh! Here we got rid of those magic mls attributes and you want to add more :) I'd much prefer a proper feature instead of special cased attribute names, just me though. The last time we got rid of magic attributes with new contraints, maybe we need an 'unconstrain' :) > Only issue is that we loose attribute names in the kernel at > present (expand strips them from the types symtab). Which we > should probably change - I'll concede it was a mistake to > omit them when I started keeping attributes in rules in > policy.20. That would let the kernel then look up > "permissive" and get the set of types that should be handled > that way. That's a format change though for the kernel, even > if module format is unaffected. > :) > That would also have a side benefit for tools, as they could > finally get attribute name info from kernel policy. setools > would like that, and audit2why could use it too (to identify > what attribute would allow a constraint violation to pass). -- 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.
