I am attempting to add a secadm_r

I am attempting to add a secadm_r

[Daniel J Walsh]

I do not want to get in a conversation about how many ways there are 
around this, from sysadm_r.   I know that, but when I was at DOD
a couple of weeks ago they stated that they wanted a separate role from 
policy management, from the role of the system administrator.  They
did not care about this being protected, but wanted a way to stop 
accidentally modifying the machine.  In DOD the System Administrator and
the Security Administrator are different roles. 

Any ways trying a simple experiment I have added the following  roles

role secadm_r types sysadm_t
role secadm_r types checkpolicy_t
role secadm_r types newrole_t

And I add secadm_r as a "root" role in the users file.

Now when I try to newrole from root:sysadm_r:sysadm_t to 
root:secadm_r:sysadm_t

I get a process transition failure

from

root:sysadm_r:newrole_t to root:secadm_r:sysadm_t.

What am I missing?

the
allow newrole_t sysadm_t:process transition;

rule exists

-- 



--
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: I am attempting to add a secadm_r

[Luke Kenneth Casson Leighton]

On Thu, Apr 07, 2005 at 11:38:21AM -0400, Daniel J Walsh wrote:

> around this, from sysadm_r.   I know that, but when I was at DOD
> a couple of weeks ago they stated that they wanted a separate role from 
> policy management, from the role of the system administrator.  They
> did not care about this being protected, but wanted a way to stop 
> accidentally modifying the machine.  In DOD the System Administrator and
> the Security Administrator are different roles. 
 
 GREAT - if you get this working and can make it "look" like
 the present method by setting secadm_r as an alias to sysadm_r
 so it "looks" like sysadm_r has policy modification rights,
 i would be DELIGHTED.

 i too have a situation where a day-to-day operator is given _far_ too
 much rights - including the right to be able to switch off selinux,
 modify policy etc.

 this is _way_ too trusting of the day-to-day operator, who
 otherwise needs root-style access in order to manage files
 in a special transfer area, and do other things to the box
 that require root-level privileges (such as adding new user
 accounts and setting up new file transfer areas)

 if someone knows of a way to have two logins, one of which requires
 one password to get to root-with-sysadm_r privileges, and one of which
 requires a DIFFERENT password to get to root-with-secadm_r privileges,
 and never the two shall meet, i would be DELIGHTED to hear of such a
 method.

 i have a customer in the process of testing the system i have set up
 for them and i would like to be able to tell them that it is not
 necessary to hammer into the operator that they must not do things like
 disable selinux, edit the policy, i want to be able to tell them the
 operator CANNOT disable selinux, edit the policy - but they can still
 run adduser.

 any assistance greatly appreciated.

 l.


--
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: I am attempting to add a secadm_r

[Stephen Smalley]

On Thu, 2005-04-07 at 17:46 +0100, Luke Kenneth Casson Leighton wrote:
>  if someone knows of a way to have two logins, one of which requires
>  one password to get to root-with-sysadm_r privileges, and one of which
>  requires a DIFFERENT password to get to root-with-secadm_r privileges,
>  and never the two shall meet, i would be DELIGHTED to hear of such a
>  method.

What prevents you from doing what you describe via two usernames
in /etc/passwd that both map to uid 0 but have different role
authorizations in policy/users?

>  i have a customer in the process of testing the system i have set up
>  for them and i would like to be able to tell them that it is not
>  necessary to hammer into the operator that they must not do things like
>  disable selinux, edit the policy, i want to be able to tell them the
>  operator CANNOT disable selinux, edit the policy - but they can still
>  run adduser.

CANNOT is too strong for what Dan is suggesting; the operator could
still likely ultimately gain access to secadm via subversion of anything
on which secadm relies; the simple role separation suggested by Dan is
mostly just to reduce likelihood of mistakes by sysadm affecting the
policy or labeling.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
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: I am attempting to add a secadm_r

[Luke Kenneth Casson Leighton]

On Thu, Apr 07, 2005 at 01:00:53PM -0400, Stephen Smalley wrote:
> On Thu, 2005-04-07 at 17:46 +0100, Luke Kenneth Casson Leighton wrote:
> >  if someone knows of a way to have two logins, one of which requires
> >  one password to get to root-with-sysadm_r privileges, and one of which
> >  requires a DIFFERENT password to get to root-with-secadm_r privileges,
> >  and never the two shall meet, i would be DELIGHTED to hear of such a
> >  method.
> 
> What prevents you from doing what you describe via two usernames
> in /etc/passwd that both map to uid 0 but have different role
> authorizations in policy/users?
 
 prevents... nothing ... i remember something appearing to go
 wrong when i did that last - something to do with samba, it
 ended up at the username "root" even though i'd logged in as
 "root2".

 in this instance, it'd not be a problem.

 thanks for prompting me on this, stephen.


> >  i have a customer in the process of testing the system i have set up
> >  for them and i would like to be able to tell them that it is not
> >  necessary to hammer into the operator that they must not do things like
> >  disable selinux, edit the policy, i want to be able to tell them the
> >  operator CANNOT disable selinux, edit the policy - but they can still
> >  run adduser.
> 
> CANNOT is too strong for what Dan is suggesting; the operator could
> still likely ultimately gain access to secadm via subversion of anything
> on which secadm relies; the simple role separation suggested by Dan is
> mostly just to reduce likelihood of mistakes by sysadm affecting the
> policy or labeling.

 in the scenario i describe, which i mention in case dan could
 incorporate it (it may happen to be the same thing), i would like
 secadm to be able to do policy / labelling, and for sysadm to _not_
 be able to.

 if secadm could be drastically restricted to pretty much only be
 able to run policy / labelling selinux command tools - even better.

 l.


--
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: I am attempting to add a secadm_r

[Stephen Smalley]

On Thu, 2005-04-07 at 18:45 +0100, Luke Kenneth Casson Leighton wrote:
>  in the scenario i describe, which i mention in case dan could
>  incorporate it (it may happen to be the same thing), i would like
>  secadm to be able to do policy / labelling, and for sysadm to _not_
>  be able to.

Right, that is what Dan intends, IIUC.  But while you can (relatively)
easily prevent sysadm from directly modifying policy, loading it, and
relabeling files, you cannot easily prevent him from indirectly
achieving the same ends without greatly stripping away his privileges
even for ordinary administrative work, as I and others have mentioned in
the past (yes, I know Dan doesn't want to revive that discussion, but I
did want to make sure that Luke remembers it since he is asking about
this).   e.g. see the thread starting at 
http://marc.theaimsgroup.com/?l=selinux&m=105457887918050&w=2

>  if secadm could be drastically restricted to pretty much only be
>  able to run policy / labelling selinux command tools - even better.

Problematic at present, given that policy is modified in source form,
unless you want to require all policy modifications to be done off-line
and then only allow updated binary policy to be installed by the secadm.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
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: I am attempting to add a secadm_r

[Luke Kenneth Casson Leighton]

On Thu, Apr 07, 2005 at 01:39:36PM -0400, Stephen Smalley wrote:

> >  if secadm could be drastically restricted to pretty much only be
> >  able to run policy / labelling selinux command tools - even better.
> 
> Problematic at present, given that policy is modified in source form,
> unless you want to require all policy modifications to be done off-line
> and then only allow updated binary policy to be installed by the secadm.

 the arrangement that i have is complicated by the fact that
 when a new user is added, some additions to about three
 policy source files are also required, which defines some new
 domains under which the user is exclusively allowed access to
 a subdirectory of the transfer area and to that area _alone_.

 i am therefore giving serious consideration to writing this as a
 script, which the day-to-day operator will be allowed to run (yes,
 there could end up being hundreds of new users, each with their own
 separate and exclusively accessible transfer area)

 and setting up a domain under which this script can be run, and
 allowing the operator to run it.

 that is the _only_ way that i would normally like policy to
 be modifiable on this system - except possibly by sysadm_r.

 i could then give serious consideration to allowing staff_r the right
 to run this magic script.


 ... i get the impression that it might be better to have
 a sysadm_r role (as it presently is) which is allowed
 "EVVERRYTHING", and a second-tier role which is allowed
 "everything-sysadm-can-presently-do-except-policy-related-stuff".

 l.


--
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: I am attempting to add a secadm_r

[Russell Coker]

On Friday 08 April 2005 03:45, Luke Kenneth Casson Leighton <lkcl@lkcl.net> 
wrote:
> > What prevents you from doing what you describe via two usernames
> > in /etc/passwd that both map to uid 0 but have different role
> > authorizations in policy/users?
>
>  prevents... nothing ... i remember something appearing to go
>  wrong when i did that last - something to do with samba, it
>  ended up at the username "root" even though i'd logged in as
>  "root2".

It's annoying that $USER and $LOGNAME have the first entry in the passwd file 
that has the right UID.  Maybe the best thing to do would be to have 
~/.bashrc or /etc/profile set $USER and $LOGNAME based on $HOME.  There's 
nothing we can do about "id -un" though.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
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: I am attempting to add a secadm_r

[Stephen Smalley]

On Thu, 2005-04-07 at 11:38 -0400, Daniel J Walsh wrote:
> Any ways trying a simple experiment I have added the following  roles
> 
> role secadm_r types sysadm_t
> role secadm_r types checkpolicy_t
> role secadm_r types newrole_t
> 
> And I add secadm_r as a "root" role in the users file.

Normally, to add a new user role, you would add the following lines to
domains/user.te:
	full_user_role(secadm)
This will define both a secadm_r role and a secadm_t domain, along with
associated types.  Then you can replace role and domain transitions for
sysadm with corresponding ones in the specific program domains like
checkpolicy, load_policy, setfiles, restorecon, etc so that secadm can
enter those domains but sysadm cannot.

> Now when I try to newrole from root:sysadm_r:sysadm_t to 
> root:secadm_r:sysadm_t

newrole transitions are typically authorized by the role_tty_type_change
() macro in domains/user.te.  This sets up the role allow rules and
type_change roles for the transition.

> I get a process transition failure
> 
> from
> 
> root:sysadm_r:newrole_t to root:secadm_r:sysadm_t.
> 
> What am I missing?
> 
> the
> allow newrole_t sysadm_t:process transition;
> 
> rule exists

You likely lack an 'allow sysadm_r secadm_r;' rule for the role
transition.  This would normally be covered by the role_tty_type_change
macro.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
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: I am attempting to add a secadm_r

[Stephen Smalley]

On Thu, 2005-04-07 at 12:54 -0400, Stephen Smalley wrote:
> Normally, to add a new user role, you would add the following lines to
> domains/user.te:
> 	full_user_role(secadm)
> This will define both a secadm_r role and a secadm_t domain, along with
> associated types.  Then you can replace role and domain transitions for
> sysadm with corresponding ones in the specific program domains like
> checkpolicy, load_policy, setfiles, restorecon, etc so that secadm can
> enter those domains but sysadm cannot.

Note btw that you will want this to be a tunable so that people can
still choose to have sysadm be all powerful if desired.

-- 
Stephen Smalley <sds@tycho.nsa.gov>
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: I am attempting to add a secadm_r

[Stephen Smalley]

On Thu, 2005-04-07 at 12:54 -0400, Stephen Smalley wrote:
> Normally, to add a new user role, you would add the following lines to
> domains/user.te:
> 	full_user_role(secadm)
> This will define both a secadm_r role and a secadm_t domain, along with
> associated types.  Then you can replace role and domain transitions for
> sysadm with corresponding ones in the specific program domains like
> checkpolicy, load_policy, setfiles, restorecon, etc so that secadm can
> enter those domains but sysadm cannot.

Note that this will mean that you want to add a "secadm_r:secadm_t" line
to the default_type file.   Then, if you add role_type_tty_change rules
from whatever starting role you use for the user, then you should be
able to newrole -r secadm_r to get to secadm_r:secadm_t.  Defining a new
role without defining a new initial domain is pointless; you haven't
achieved any real separation.

-- 
Stephen Smalley <sds@tycho.nsa.gov>
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: I am attempting to add a secadm_r

[Daniel J Walsh]

Stephen Smalley wrote:

>On Thu, 2005-04-07 at 12:54 -0400, Stephen Smalley wrote:
>  
>
>>Normally, to add a new user role, you would add the following lines to
>>domains/user.te:
>>	full_user_role(secadm)
>>This will define both a secadm_r role and a secadm_t domain, along with
>>associated types.  Then you can replace role and domain transitions for
>>sysadm with corresponding ones in the specific program domains like
>>checkpolicy, load_policy, setfiles, restorecon, etc so that secadm can
>>enter those domains but sysadm cannot.
>>    
>>
>
>Note that this will mean that you want to add a "secadm_r:secadm_t" line
>to the default_type file.   Then, if you add role_type_tty_change rules
>from whatever starting role you use for the user, then you should be
>able to newrole -r secadm_r to get to secadm_r:secadm_t.  Defining a new
>role without defining a new initial domain is pointless; you haven't
>achieved any real separation.
>
>  
>
Ok, this is the point I was trying to understand.  I was hoping I could 
define a role without defining
an initial type.  I was hoping for secadm_r:sysadm_t or 
secadm_r:staff_t.  Forcing a new initial type,
seems a little touch.  This causes the creation of new roles to be more 
difficult. 

I would have thought you could define a staff_t and then depending on 
which roles they were currently
under, which domains they could reach.

So staff_r:staff_t can not add users.
But useradd_r:staff_t can.

I would want to eliminate the su transition to sysadm_r:sysadm_t and 
force say a staff user to
newrole -r secadm_r

and become secadm_r:staff_t and then su and be able to do the 
checkpolicy/load_policy type stuff.

If I do full_user_role I get alot more privs then I necessarily want.

Dan

-- 



--
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: I am attempting to add a secadm_r

[Stephen Smalley]

On Thu, 2005-04-07 at 15:25 -0400, Daniel J Walsh wrote:
> Ok, this is the point I was trying to understand.  I was hoping I could 
> define a role without defining
> an initial type.  I was hoping for secadm_r:sysadm_t or 
> secadm_r:staff_t.  Forcing a new initial type,
> seems a little touch.  This causes the creation of new roles to be more 
> difficult. 
> 
> I would have thought you could define a staff_t and then depending on 
> which roles they were currently
> under, which domains they could reach.
> 
> So staff_r:staff_t can not add users.
> But useradd_r:staff_t can.

That doesn't really work, because the process-to-object permissions are
primarily determined based on the TE rules, so a staff_r:staff_t process
can control a useradd_r:staff_t process (unless you start adding a lot
of constraints over permissions based on roles).  Further, in this
particular case, as I understand it, you truly want a real user role,
not just a specialized pseudo role for particular programs, because you
want to be able to assign secadm to one person and sysadm to another
person, and have them fully separated from one another, not just one
person switching back and forth via newrole or invoking a program in a
role via sudo or userhelper. 

> I would want to eliminate the su transition to sysadm_r:sysadm_t and 
> force say a staff user to
> newrole -r secadm_r
> 
> and become secadm_r:staff_t and then su and be able to do the 
> checkpolicy/load_policy type stuff.

The su pam_selinux integration makes this a bit harder too, as we want
to convey uid 0 / Linux capabilities to the process without forcing them
to a single SELinux user identity.  Of course, as I noted to Luke, you
could have multiple /etc/passwd accounts with uid 0 and map the
usernames to different roles in policy/users.

> If I do full_user_role I get alot more privs then I necessarily want.

You can certainly create a stripped down version of full_user_role that
is much more minimal in its permissions, but you still need a distinct
initial domain for the role to protect it from subversion by other
roles.
  
-- 
Stephen Smalley <sds@tycho.nsa.gov>
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: I am attempting to add a secadm_r

[Russell Coker]

On Friday 08 April 2005 05:25, Daniel J Walsh <dwalsh@redhat.com> wrote:
> Ok, this is the point I was trying to understand.  I was hoping I could
> define a role without defining
> an initial type.  I was hoping for secadm_r:sysadm_t or
> secadm_r:staff_t.  Forcing a new initial type,
> seems a little touch.  This causes the creation of new roles to be more
> difficult.
>
> I would have thought you could define a staff_t and then depending on
> which roles they were currently
> under, which domains they could reach.
>
> So staff_r:staff_t can not add users.
> But useradd_r:staff_t can.

Sure that could be done:

domain_auto_trans(staff_t, useradd_exec_t, useradd_t)
role staff_secadm_r types useradd_t;

But I agree with Steve that it doesn't offer much.  Having a separate initial 
domain for such operations makes more sense.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
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: I am attempting to add a secadm_r

[Chad Hanson]

Stephen Smalley wrote: 

>The su pam_selinux integration makes this a bit harder too, as we want
>to convey uid 0 / Linux capabilities to the process without forcing them
>to a single SELinux user identity.  Of course, as I noted to Luke, you
>could have multiple /etc/passwd accounts with uid 0 and map the
>usernames to different roles in policy/users.
>

I sort of like the idea of multiple uid 0 accounts for mapping usernames to
roles. This would seem to solve a lot of legacy problems that exist with
creating RBAC on top a traditional UID 0 based security. Creating a useful
RBAC solution requires overcoming these legacy problems. I think the mapping
approach should work well for a high level of granularity. I think the one
potential downfall is possibly having some issues when you get into a very
granular schema, because you could need a lot of uid 0 accounts.

>> If I do full_user_role I get alot more privs then I necessarily want.
>
>You can certainly create a stripped down version of full_user_role that
>is much more minimal in its permissions, but you still need a distinct
>initial domain for the role to protect it from subversion by other
>roles.

I would agree that is what would be desired for administrative and even some
user roles. 

-Chad

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