On Tue, 2009-09-15 at 08:32 +0200, Michal Svoboda wrote: > Stephen Smalley wrote: > > I don't think so - the problem with selinuxfs tunables is that they > > can't be changed atomically with a policy change, and this is a property > > that should be tied to a particular policy. For the same reason, > > properties like handle_unknown and permissive domains are defined in the > > policy itself rather than being selinuxfs tunables. > > There have been things like compat_net, why can't the inheritance be > done on the same basis and must be part of the policy instead? compat_net was viewed as a mistake in retrospect, something we don't want to repeat. > Anyway, I've been looking at the policy loader code, and it seems that > the easiest way to incorporate this into the policy would be to blend it > with the config field (which is presently used for MLS and > handle_unknown flags), perhaps by defining a flag like CATEGORY_INHERIT > and to check for it right after ALLOW_UNKNOWN and REJECT_UNKNOWN are > processed. This flag would then go to struct policydb and would be > checked for in the mls_compute_sid function (I can see direct usage of > the policydb global variable in that very function, so I guess it > shouldn't be a problem). > > Perhaps there could also be an upgrade of the policy version number and > a check for the policy being loaded just to prevent random values being > present in that bit. > > There would also need to be a change in libsepol and checkpolicy to > reflect this; perhaps checkpolicy could accept an additional command > line argument (as it does with handle_unknown), and a new field defined > in libsepol's policydb_t and further processed in its write.c. Sounds about right to me. It would technically be MLS_RANGE_INHERIT or similar since it involves more than just the categories. It might be cleaner to make it an actual statement in the policy language rather than a checkpolicy option, so that policy/mls or policy/mcs declares the desired default transition behavior for objects, at which point you'd generalize it. The current behavior is copy-low-from-source; you want copy-range-from-target. But others might want copy-high-from-source or copy-high-from-target or copy-low-from-target or copy-range-from-source. -- 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.
