So for my purposes, to would probably be best to just make a secadm user/role and add follow most of the interface for the original secadm role? On Fri, 2008-02-15 at 10:39 -0500, Christopher J. PeBenito wrote: > On Fri, 2008-02-15 at 10:16 -0500, Stephen Smalley wrote: > > On Fri, 2008-02-15 at 09:09 -0600, Jeremiah Jahn wrote: > > > So if I change my build.conf to be mls I should be up and running. I'm > > > on RHEL5 btw > > > > Chris - how hard would it be to make this a separate tunable so that > > people who want a separate security admin can turn that on without > > enabling MLS? > > Problematic. The security admin pieces are nicely abstracted into an > interface. However, the problem is that it has some typeattribute > statements, so we can't put that in a conditional. > > There are two things that will eventually make this possible. The plan > is to move roles into their own modules, and at that point you should be > able to just insert the secadm module. > > > > On Fri, 2008-02-15 at 08:55 -0500, Paul Moore wrote: > > > > On Thursday 14 February 2008 6:09:43 pm Jeremiah Jahn wrote: > > > > > I see a number of places where the secadm_r role shows up, but It > > > > > doesn't show up in the list of users and what not, Is there something > > > > > simple I need to enable it, or do I need to build it from scratch? > > > > > My goal it to have sysadm not able to modify policy enforcement, and > > > > > my secadm not be able to do anything but. If there is a standard way > > > > > to do this, I'd love to know. > > > > > > > > I believe the secadm_r role is only defined for the "mls" policy builds; > > > > if you are running a "mcs" (the Fedora default) policy I don't think > > > > the secadm_r role is present. > > > > > > > Boy, n.: A noise with dirt on it. "Consequences, Schmonsequences, as long as I'm rich." -- "Ali Baba Bunny" [1957, Chuck Jones]
Attachment:
signature.asc
Description: This is a digitally signed message part
