This is an important feature to the customer. My team has managed to differ this until a later release. Hopefully one of the 6.x versions.
They like SELinux MLS because so far their, Solaris TX and ZFS systems cannot label data at rest. They have TX systems that they want to migrate away from.
Thanks for the help
On Thu, Jan 20, 2011 at 12:05 PM, Qwyjibo Jones <qwyjibojones@xxxxxxxxx> wrote:
Okay,
We aren't using any desktop right now. this system is a headless server.
As for how important... Well if you ask me, (the sysadmin), I would say not very. But alas it is not up to me. I will have to get the customer (Govt) to tell me how much they need this. Perhaps I can get them to wait until 6.1 comes out since they are thinking of a hardware refresh anyhow.
My current policy skills are probably insufficient to the task of making the policy you described. I can use audit2allow pretty well tho... :)
Thanks,On Thu, Jan 20, 2011 at 9:23 AM, Daniel J Walsh <dwalsh@xxxxxxxxxx> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/20/2011 08:45 AM, Qwyjibo Jones wrote:
> Sorry, one more question...
>
> Does the MLS policy shipped with RHEL 6 have the separation?
>
> Thanks,
>
> On Wed, Jan 19, 2011 at 4:51 PM, Daniel J Walsh <dwalsh@xxxxxxxxxx
> <mailto:dwalsh@xxxxxxxxxx>> wrote:
>
> On 01/19/2011 04:44 PM, Qwyjibo Jones wrote:
>> I don't seem to have the "allow_sysadm_manage_security" boolean. Do I
>> need to create it somehow and put it under /selinux/booleans ?
>
>> # getsebool -a | grep allow_sysadm_manage_security
>> # getsebool -a | grep allow_sysadm
>> # getsebool -a | grep sysadm
>> allow_httpd_sysadm_script_anon_write --> off
>> ssh_sysadm_login --> off
>> staff_read_sysadm_file --> off
>> xdm_sysadm_login --> off
>
>
>
>> Thanks,
>
>> On Wed, Jan 19, 2011 at 3:11 PM, Daniel J Walsh <dwalsh@xxxxxxxxxx
> <mailto:dwalsh@xxxxxxxxxx>
One idea would be to build the separation into a separate module>> <mailto:dwalsh@xxxxxxxxxx <mailto:dwalsh@xxxxxxxxxx>>> wrote:
>
>> On 01/18/2011 01:03 PM, Qwyjibo Jones wrote:
>
>>> I am currently working with an Itanium2 system which has RHEL 5.3 MLS
>>> installed.
>>> I am trying to understand how separation of roles works in
> SELinux/MLS
>>> policy version 21. We have been told that we need to separate
>> roles that
>>> the sys admin is no longer allowed to do.
>
>>> After reading through these threads, in the archives I am still
>>> wondering about a couple things:
>
>
>
> http://www.nsa.gov/research/selinux/list-archive/0504/thread_body66.shtml#11082
>
>>> And this one:
>
>
> http://www.nsa.gov/research/selinux/list-archive/0802/thread_body60.shtml
>
>>> 1) Is the RHEL 5.x MLS policy version 21 capable of the following
>>> separation of sysadm_r and secadm_r roles:
>
>>> a) Can the secadm_r role be the only role that can assign
> roles via
>>> semanage?
>
>>> c) Can the secadm_r role be the only role that can control
>> files used
>>> in auditing, like auditd.conf. audit.rules, /etc/init.d/auditd etc...
>
>> auditadm_r:auditadm_t is only allowed to modify these files.
>
>>> 2) Is this better accomplished with a combination of SUDO and
> SELinux?
>> Since sysadm_t can hack his way around the SELinux controls via tools
>> like rpm and fdisk, you are better off using sudo to further restrict
>> his actions, if possible.
>>> 3) How can I determine what secadm_r can do in the current
>>> configuration? can any of the CLI tools show me that? ( no gui tools
>>> available )
>
>> You probably want to look at secadm_t
>
>> sesearch -A -t secadm_t
>
>>> If not, what about RHEL 6 ? ( I understand RHEL 6 is not available to
>>> Itanium systems, but we may have new hardware soon)
>
>>> Any tips. hints, pointers etc... would be very helpfull.
>
>>> Thanks for your time,
>
> Oops I misread the policy, I guess we abandoned the separation.
>
>
> ifdef(`enable_mls',`
>
> userdom_security_administrator(secadm_t,secadm_r,{
> secadm_tty_device_t sysadm_devpts_t })
> # tunable_policy(`allow_sysadm_manage_security',`
>
> userdom_security_administrator(sysadm_t,sysadm_r,admin_terminal)
> # ')
>
>
> Missed the "#" at the beginning of the lines. So I don't think we
> prevent sysadm_t from managing the security, of course he has to be able
> to run at SystemHigh.
>
sysadm_secadm.pp then you could disable this module and take away the
power of sysadm to do security administration. How important is this?
-----BEGIN PGP SIGNATURE-----iEYEARECAAYFAk04RWcACgkQrlYvE4MpobNgkwCgrpfXVA3VACrLFueZjW6V5Gko
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
YRsAoJsGGp76ODNFPSIhpl24h4D5KA6A
=Ae9m
-----END PGP SIGNATURE-----
