secadm question

secadm question

[Jeremiah Jahn]

[-- Attachment #1: Type: text/plain, Size: 457 bytes --]

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.

thanx,
-jj-



Things are more like they used to be than they are now.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: secadm question

[Paul Moore]

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.

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: secadm question

[Jeremiah Jahn]

[-- Attachment #1: Type: text/plain, Size: 834 bytes --]

So if I change my build.conf to be mls I should be up and running. I'm
on RHEL5 btw

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.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: secadm question

[Stephen Smalley]

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?

> 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.
-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: secadm question

[Paul Moore]

On Friday 15 February 2008 10:09:47 am Jeremiah Jahn wrote:
> So if I change my build.conf to be mls I should be up and running.
> I'm on RHEL5 btw

Yes, setting the TYPE to "mls" should enable the secadm_r role.  If you 
don't need the latest Reference Policy, there is a MLS policy as part 
of RHEL5 - it's what was used for the recent (okay, maybe not that 
recent anymore) Common Criteria LSPP evaluations.

> 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.

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: secadm question

[Stephen Smalley]

On Fri, 2008-02-15 at 10:18 -0500, Paul Moore wrote:
> On Friday 15 February 2008 10:09:47 am Jeremiah Jahn wrote:
> > So if I change my build.conf to be mls I should be up and running.
> > I'm on RHEL5 btw
> 
> Yes, setting the TYPE to "mls" should enable the secadm_r role.  If you 
> don't need the latest Reference Policy, there is a MLS policy as part 
> of RHEL5 - it's what was used for the recent (okay, maybe not that 
> recent anymore) Common Criteria LSPP evaluations.

Using the -mls policy from RHEL5 is somewhat limiting as it excludes
various parts of the policy not covered by the evaluation (e.g. little
things like X Window System support).

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: secadm question

[Christopher J. PeBenito]

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.
-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: secadm question

[Jeremiah Jahn]

[-- Attachment #1: Type: text/plain, Size: 1936 bytes --]

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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: secadm question

[Christopher J. PeBenito]

On Fri, 2008-02-15 at 10:09 -0600, Jeremiah Jahn wrote:
> 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?

You could do that, but it wouldn't stop sysadm from being able to do all
the secadm things too, defeating the purpose of having a secadm in the
first place :)

> 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]
-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: secadm question

[Jeremiah Jahn]

[-- Attachment #1: Type: text/plain, Size: 2559 bytes --]

true, but I thought there was a tunable/boolean the disabled all that
for sysadm

On Fri, 2008-02-15 at 11:09 -0500, Christopher J. PeBenito wrote:
> On Fri, 2008-02-15 at 10:09 -0600, Jeremiah Jahn wrote:
> > 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?
> 
> You could do that, but it wouldn't stop sysadm from being able to do all
> the secadm things too, defeating the purpose of having a secadm in the
> first place :)
> 
> > 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]
First Law of Bicycling: No matter which way you ride, it's uphill and
against the wind.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: secadm question

[Christopher J. PeBenito]

On Fri, 2008-02-15 at 10:14 -0600, Jeremiah Jahn wrote:
> true, but I thought there was a tunable/boolean the disabled all that
> for sysadm

No, there isn't.  It suffers the problems I discussed below.

> On Fri, 2008-02-15 at 11:09 -0500, Christopher J. PeBenito wrote:
> > On Fri, 2008-02-15 at 10:09 -0600, Jeremiah Jahn wrote:
> > > 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?
> > 
> > You could do that, but it wouldn't stop sysadm from being able to do all
> > the secadm things too, defeating the purpose of having a secadm in the
> > first place :)
> > 
> > > 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]
> First Law of Bicycling: No matter which way you ride, it's uphill and
> against the wind.
-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: secadm question

[Jeremiah Jahn]

[-- Attachment #1: Type: text/plain, Size: 3163 bytes --]

Since I'm working with the source, Would it be effective for me to go
through and remove the sysadm rules that allow it to futz w/ the
policies? 

On Fri, 2008-02-15 at 11:23 -0500, Christopher J. PeBenito wrote:
> On Fri, 2008-02-15 at 10:14 -0600, Jeremiah Jahn wrote:
> > true, but I thought there was a tunable/boolean the disabled all that
> > for sysadm
> 
> No, there isn't.  It suffers the problems I discussed below.
> 
> > On Fri, 2008-02-15 at 11:09 -0500, Christopher J. PeBenito wrote:
> > > On Fri, 2008-02-15 at 10:09 -0600, Jeremiah Jahn wrote:
> > > > 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?
> > > 
> > > You could do that, but it wouldn't stop sysadm from being able to do all
> > > the secadm things too, defeating the purpose of having a secadm in the
> > > first place :)
> > > 
> > > > 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]
> > First Law of Bicycling: No matter which way you ride, it's uphill and
> > against the wind.
San Francisco, n.: Marcel Proust editing an issue of Penthouse.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: secadm question

[Christopher J. PeBenito]

On Fri, 2008-02-15 at 10:36 -0600, Jeremiah Jahn wrote:
> Since I'm working with the source, Would it be effective for me to go
> through and remove the sysadm rules that allow it to futz w/ the
> policies? 

Sure, if you're willing to change the base policy then you can get it
all done.

> On Fri, 2008-02-15 at 11:23 -0500, Christopher J. PeBenito wrote:
> > On Fri, 2008-02-15 at 10:14 -0600, Jeremiah Jahn wrote:
> > > true, but I thought there was a tunable/boolean the disabled all that
> > > for sysadm
> > 
> > No, there isn't.  It suffers the problems I discussed below.
> > 
> > > On Fri, 2008-02-15 at 11:09 -0500, Christopher J. PeBenito wrote:
> > > > On Fri, 2008-02-15 at 10:09 -0600, Jeremiah Jahn wrote:
> > > > > 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?
> > > > 
> > > > You could do that, but it wouldn't stop sysadm from being able to do all
> > > > the secadm things too, defeating the purpose of having a secadm in the
> > > > first place :)
> > > > 
> > > > > 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]
> > > First Law of Bicycling: No matter which way you ride, it's uphill and
> > > against the wind.
> San Francisco, n.: Marcel Proust editing an issue of Penthouse.
-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

secadm/sysadm discussion

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

<rant>


Personally I think sysadm_t is a waste of time.  It is a poor mans
unconfined_t and should be eliminated from the face of the earth.  All
it does is generate Bugs and avc messages without supplying any real
security.  It makes no sense, as a confinement of a root user since it
is so easily gotten around.  If you have an administrator of a machine,
that you want to confine, start with only allowing him the privs that
are required to do his job.  You can't start by saying he can do
everything except ABC.

If your goal is the admin can not modify the SELinux security policy and
you don't trust the admin, you loose.  The admin can use fsadm tools, he
can use rpm, he can bring the machine to single user mode he can modify
init.

You need to define what the confined admin is allowed to manage
Apache/postgrsql/mysql and then define rules and a domain for an
administrator to do that.

Fedora 9 will have the ability to easily design an confined admin role.
 I have added NAME_admin interfaces to every confined service domain,
and system-config-selinux/polgengui now has the ability to select the
NAME_admin domains that you want to administer.  I believe this is the
way to confine a root user.  You can than setup a confined login user
staff_t or guest_t and define transitions from this domain to the admin
domain.  sudo can now be used to handle the transition.

I think we will find lots of bugs in this method, but we need people to
experiment with it.  I think we will also find security vulnerabilities
which we will need to fix in the kernel.  (chmod 4755 shell) for example.



</rant>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAke2AncACgkQrlYvE4MpobN2zgCfTs1WPmpgUm5m8wo50Vwcpb9J
jy0AnAibTphoR0N2DgUG45cv3HIfkqZV
=xBer
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

secadm/sysadm discussion

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

<rant>


Personally I think sysadm_t is a waste of time.  It is a poor mans
unconfined_t and should be eliminated from the face of the earth.  All
it does is generate Bugs and avc messages without supplying any real
security.  It makes no sense, as a confinement of a root user since it
is so easily gotten around.  If you have an administrator of a machine,
that you want to confine, start with only allowing him the privs that
are required to do his job.  You can't start by saying he can do
everything except ABC.

If your goal is the admin can not modify the SELinux security policy and
you don't trust the admin, you loose.  The admin can use fsadm tools, he
can use rpm, he can bring the machine to single user mode he can modify
init.

You need to define what the confined admin is allowed to manage
Apache/postgrsql/mysql and then define rules and a domain for an
administrator to do that.

Fedora 9 will have the ability to easily design an confined admin role.
 I have added NAME_admin interfaces to every confined service domain,
and system-config-selinux/polgengui now has the ability to select the
NAME_admin domains that you want to administer.  I believe this is the
way to confine a root user.  You can than setup a confined login user
staff_t or guest_t and define transitions from this domain to the admin
domain.  sudo can now be used to handle the transition.

I think we will find lots of bugs in this method, but we need people to
experiment with it.  I think we will also find security vulnerabilities
which we will need to fix in the kernel.  (chmod 4755 shell) for example.



</rant>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAke2AncACgkQrlYvE4MpobN2zgCfTs1WPmpgUm5m8wo50Vwcpb9J
jy0AnAibTphoR0N2DgUG45cv3HIfkqZV
=xBer
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: secadm/sysadm discussion

[Russell Coker]

On Saturday 16 February 2008 08:22, Daniel J Walsh <dwalsh@redhat.com> wrote:
> Personally I think sysadm_t is a waste of time.  It is a poor mans
> unconfined_t and should be eliminated from the face of the earth.

I agree.

For those who aren't aware of the history sysadm_t predates unconfined_t by 
years and was used for things for which unconfined_t is now used.

There is also a conceptual difference, as indicated by the name sysadm_t was 
for system administration not regular user sessions.  Many of the problems 
with user_t which drove the development of the Targeted policy would not have 
occurred if sysadm_t had been used for all users (although even if that had 
been done there was still need for unconfined_t at that time).

> All 
> it does is generate Bugs and avc messages without supplying any real
> security.  It makes no sense, as a confinement of a root user since it
> is so easily gotten around.

Also the sysadm_t vs secadm_t distinction is even worse in some ways.

> Fedora 9 will have the ability to easily design an confined admin role.
>  I have added NAME_admin interfaces to every confined service domain,
> and system-config-selinux/polgengui now has the ability to select the
> NAME_admin domains that you want to administer.  I believe this is the
> way to confine a root user.  You can than setup a confined login user
> staff_t or guest_t and define transitions from this domain to the admin
> domain.  sudo can now be used to handle the transition.

Good work.  I had experimented with such things in the past, but policy now 
supports them in a better manner (without getting the macro hell).

> I think we will find lots of bugs in this method, but we need people to
> experiment with it.  I think we will also find security vulnerabilities
> which we will need to fix in the kernel.  (chmod 4755 shell) for example.

While I agree with the general concept, chmod 4755 shell doesn't do what you 
imagine for the common shells (at least the shells I tested last time I saw 
this issue on a mailing list).  Similar chcon commands will however allow you 
to do interesting things.

-- 
russell@coker.com.au
http://etbe.coker.com.au/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: secadm/sysadm discussion

[Christopher J. PeBenito]

On Fri, 2008-02-15 at 16:22 -0500, Daniel J Walsh wrote:
> <rant>
> 
> 
> Personally I think sysadm_t is a waste of time.  It is a poor mans
> unconfined_t and should be eliminated from the face of the earth.  All
> it does is generate Bugs and avc messages without supplying any real
> security.  It makes no sense, as a confinement of a root user since it
> is so easily gotten around.  If you have an administrator of a machine,
> that you want to confine, start with only allowing him the privs that
> are required to do his job.  You can't start by saying he can do
> everything except ABC.

As long as policy is used in a strict configuration, sysadm will be
needed.  I would prefer to tighten it up.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: secadm/sysadm discussion

[Chad Hanson]

I would concur that something like sysadm is needed.  But in the current
mls/strict configuration sysadm has too much power. 

The ability to customize roles and there respective powers in a modular
manner seems like a good idea. Hopefully this could lead to more
directed policy instead of blanket allow rules. These are hard to deal
with when people require changes to the default behavior.

-Chad

> On Fri, 2008-02-15 at 16:22 -0500, Daniel J Walsh wrote:
> > <rant>
> > 
> > 
> > Personally I think sysadm_t is a waste of time.  It is a poor mans
> > unconfined_t and should be eliminated from the face of the earth.
All
> > it does is generate Bugs and avc messages without supplying any real
> > security.  It makes no sense, as a confinement of a root user since
it
> > is so easily gotten around.  If you have an administrator of a
machine,
> > that you want to confine, start with only allowing him the privs
that
> > are required to do his job.  You can't start by saying he can do
> > everything except ABC.
> 
> As long as policy is used in a strict configuration, sysadm will be
> needed.  I would prefer to tighten it up.
> 
> -- 
> Chris PeBenito
> Tresys Technology, LLC
> (410) 290-1411 x150
> 



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: secadm/sysadm discussion

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christopher J. PeBenito wrote:
> On Fri, 2008-02-15 at 16:22 -0500, Daniel J Walsh wrote:
>> <rant>
>>
>>
>> Personally I think sysadm_t is a waste of time.  It is a poor mans
>> unconfined_t and should be eliminated from the face of the earth.  All
>> it does is generate Bugs and avc messages without supplying any real
>> security.  It makes no sense, as a confinement of a root user since it
>> is so easily gotten around.  If you have an administrator of a machine,
>> that you want to confine, start with only allowing him the privs that
>> are required to do his job.  You can't start by saying he can do
>> everything except ABC.
> 
> As long as policy is used in a strict configuration, sysadm will be
> needed.  I would prefer to tighten it up.
> 
This is what I question.  If you can not define what a strict
configuration is then sysadm_t is useless.  And tightening it up a
little does nothing.  If sysadm_t can build an install an RPM all bets
are off.  If he can format disk, add users, change passwords, run su,
modify sudo, change contents of the homedir of the "sysadm_t" homedir.
Then you can not stop him.

So why carry on the charade that this is useful.  I my mind you either
fully trust your admin or you don't.  If you don't you need to define
exactly what you want him to be allowed to do, and then write policy for
that.  If you can't write policy tight enough to stop him from doing
evil things, then you need to fall back to auditing his every move.
Writing a special mishmash of admin called sysadm is a waste of time.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAke67EIACgkQrlYvE4MpobPtxACePPwf7FQeH+TME/pcZ1SvwRq8
6hYAnR3S1xw8DVjySDuJAMgw6q9bMl1M
=hqGN
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: secadm/sysadm discussion

[Jeremiah Jahn]

[-- Attachment #1: Type: text/plain, Size: 3262 bytes --]

On Tue, 2008-02-19 at 09:48 -0500, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Christopher J. PeBenito wrote:
> > On Fri, 2008-02-15 at 16:22 -0500, Daniel J Walsh wrote:
> >> <rant>
> >>
> >>
> >> Personally I think sysadm_t is a waste of time.  It is a poor mans
> >> unconfined_t and should be eliminated from the face of the earth.  All
> >> it does is generate Bugs and avc messages without supplying any real
> >> security.  It makes no sense, as a confinement of a root user since it
> >> is so easily gotten around.  If you have an administrator of a machine,
> >> that you want to confine, start with only allowing him the privs that
> >> are required to do his job.  You can't start by saying he can do
> >> everything except ABC.
> > 
> > As long as policy is used in a strict configuration, sysadm will be
> > needed.  I would prefer to tighten it up.
> > 
> This is what I question.  If you can not define what a strict
> configuration is then sysadm_t is useless.  And tightening it up a
> little does nothing.  If sysadm_t can build an install an RPM all bets
> are off.  If he can format disk, add users, change passwords, run su,
> modify sudo, change contents of the homedir of the "sysadm_t" homedir.
> Then you can not stop him.
> 
> So why carry on the charade that this is useful.  I my mind you either
> fully trust your admin or you don't.  If you don't you need to define
> exactly what you want him to be allowed to do, and then write policy for
> that.  If you can't write policy tight enough to stop him from doing
> evil things, then you need to fall back to auditing his every move.
> Writing a special mishmash of admin called sysadm is a waste of time.

This is essentially what I have done. I went through userdomain.te and
moved most references regrading sysadm to secadm or auditadm. I left
only the ones I need to do my job (Hi i'm the sysadm). I've commented
out everything that required mls to be defined and made it the default,
and then commented out any 'else' situation that defaulted to giving the
sysadm the power. initrc, logrotate, rpm etc. The thing I dislike most
about what I'm currently dealing with seem to be the cascading
transitions. from sysadm->rpm_t->initrc->my secure service for example.
I've gotten rid of all of those, and I still can't disable the sysadm
role from seeing all of the running processes in ps aux. In a perfect
world I'd like to have an abstract list of everything that can happen on
the system, and then add each role to it. I think the refpolicy is
closing in on this, but there are still some awfully detailed issues
that still have to be taken into account.  It's the permissions NOT in
userdomain.te that are where I get lost/frustrated. 

> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAke67EIACgkQrlYvE4MpobPtxACePPwf7FQeH+TME/pcZ1SvwRq8
> 6hYAnR3S1xw8DVjySDuJAMgw6q9bMl1M
> =hqGN
> -----END PGP SIGNATURE-----
From the moment I picked your book up until I put it down I was
convulsed with laughter. Some day I intend reading it. -- Groucho Marx,
from "The Book of Insults"

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]