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.