On Mon, 2004-12-06 at 16:14 -0500, Stephen Smalley wrote: > On Fri, 2004-12-03 at 13:04, Serge Hallyn wrote: > > Attached is a new version of the SELinux patch. It uses the > > lsm_adopt_next_secondary() function exported by stacker to stack > > capability underneath itself if capability, stacker, and selinux are all > > compiled in. > > I suppose the question here is whether this approach is what is > ultimately desired (delegating setup of the "next" secondary module so > that SELinux can stack specially with capabilities) or whether we just > want to get the stacker to support the same behavior and provide > adequate performance so that the SELinux secondary_ops can be discarded > altogether and one can just stack SELinux+capabilities via the stacker > module. Hmm, in order to know about the performance, I suppose stacker will need to be tested with a version of SELinux patched to not call dummy_security_ops as a secondary. Hopefully that will provide more comparable results than the last run... > As an experiment, I tried removing the use of lsm_adopt_next_secondary() > from SELinux and just letting stacker handle the stacking of > capabilities with SELinux, but the system doesn't get very far that > way. The initial restorecon on /dev from rc.sysinit (to deal with the > initial /dev populated by udev before SELinux policy is loaded) seems to > fail, and then subsequent access to /dev fails. This is on FC3 with > strict policy. I've tested FC3, but not with a strict policy. I'll look into this. thanks, -serge -- Serge Hallyn <serue@private>
This archive was generated by hypermail 2.1.3 : Mon Dec 06 2004 - 13:49:57 PST