Stephen Smalley wrote: > On Mon, 2008-02-25 at 09:53 -0500, Joshua Brindle wrote: >> Daniel J Walsh wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Stephen Smalley wrote: >>>> On Fri, 2008-02-15 at 15:17 -0500, Joshua Brindle wrote: >>>>> 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. >>>> >>>> I'm not as convinced, so possibly others should chime in too. >>>> >>>> Type attributes are intended to indicate "properties" of types. It >>>> just happens that at present, the names and semantics of those >>>> properties are entirely defined within the policy configuration. >>>> But reserving some attribute names to have well-defined semantics >>>> encoded in the policy engine itself seems a natural extension, and >>>> we did do that in the original MLS implementation for trusted >>>> subjects (and I didn't view that as necessarily a bad thing). >>>> >>>> Introducing a new language primitive each time we want to mark a >>>> set of types for special handling by the policy engine logic seems >>>> less clean to me, even aside from implementation aspects. >>>> >>>> It also makes Eric's life a lot simpler ;) No need to modify >>>> checkpolicy or the policy module logic at all. A new kernel policy >>>> version would still be required, but we would get a side benefit >>>> from it in addition to permissive domains - preservation of type >>>> attribute names in the kernel policy. >>>> >> >> I understand. I want to note though, that the TE part of the SS has >> not had policy logic built into it, at least since I've been using >> SELinux. The old hardcoded attributes were part of the hardcoded MLS >> logic but we've even replaced that with a flexible system. >> >> I'm going to borrow a page from Chad's book here and say, during >> SELinux tutorials and classes we reiterate "types and attributes have >> no meaning other than what you give them in policy" say it over and >> over til it sink in.. Oh yea, and there is this one that does (d'oh). >> >>>>> The last time we got rid of magic attributes with new contraints, >>>>> maybe we need an 'unconstrain' :) >>>> >>> I tend to agree. I think we are making policy writing far to >>> complex, with additional semantics. >>> >> >> Eh? When was the last time you saw a user have to modify a constraint >> or mlsconstraint? Those additional semantics were to make the policy >> more flexible, the users almost never interact with them. > > I think that's the point - here we want users to be able to > make existing domains permissive or introduce permissive > domains w/o having to write or modify a constraint at all. > It wouldn't require modifying a constraint any more than making something mls privileged currently does. > Also, this notion of permissive domains goes beyond the > existing security server interface. As I recall, it doesn't > just change what gets returned by security_compute_av() but > rather is something that the AVC queries (based on SID) on > the permission denied code path, like current enforcing mode. > Even better, that means we are using a magic attribute (part of the TE system) to change the behavior of the avc. AFAIK nothing in the policy really changes the avc behavior (right?). I don't want to stand in the way of this feature or anything, I'm just concerned about doing it in a hacky way vs. something more elegant. I'd like to hear others opinions, Chris? Todd? -- 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.
