Best base policy to use

Best base policy to use

[Jeremiah Jahn]

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

So I'm in the process of Upgrading my servers from RHEL5 to RHEL6. On my
RHEL5 system I had to build the reference policy from scratch in order to
prevent users from being able to  transition to init_t through initrc_t.
Basically, I want systems that have to be rebooted in order to restart
certain services, like auditd, or at least be able to split those duties
into different roles. One role can edit a file or install something, but a
different role must restart it. Because life the universe and everything
goes through initrc_t, just about anything on the system running as root can
mess with services. I'd like to highly limit things, and haven't  really
looked at any new developments in selinux for about 4 years. What's the best
way/place to start removing domain transitions and requiring additional
roles.

thanks,
-jj-

[-- Attachment #2: Type: text/html, Size: 865 bytes --]

Re: Best base policy to use

[Dominick Grift]

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



On Tue, 2011-07-05 at 17:11 -0500, Jeremiah Jahn wrote:
> So I'm in the process of Upgrading my servers from RHEL5 to RHEL6. On my
> RHEL5 system I had to build the reference policy from scratch in order to
> prevent users from being able to  transition to init_t through initrc_t.
> Basically, I want systems that have to be rebooted in order to restart
> certain services, like auditd, or at least be able to split those duties
> into different roles. One role can edit a file or install something, but a
> different role must restart it. Because life the universe and everything
> goes through initrc_t, just about anything on the system running as root can
> mess with services. I'd like to highly limit things, and haven't  really
> looked at any new developments in selinux for about 4 years. What's the best
> way/place to start removing domain transitions and requiring additional
> roles.

Main difference between el5 and el6 policy is that el6 policy is a
hybrid policy of the old targeted and strict policy. (strict policy was
merged into targeted policy)

You  can now tune your policy to make it behave like the old strict
policy by removing or disabling the unconfined and unconfineduser
modules.

In Redhat policy only unconfined_t can transition directly to initrc.
Sysadm_t needs to use run_init to transition to initrc_t in the system_r
role.

el6 policy allows you to easily create new roles.

So what you could do in my view is, disable or remove both unconfined
and unconfineduser modules and then create your own roles, selinux user
identities and logins.

In that regard el6 policy has pretty much the same properties as current
reference policy.

> thanks,
> -jj-

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

Re: Best base policy to use

[Russell Coker]

On Wed, 6 Jul 2011, Jeremiah Jahn <jeremiah@goodinassociates.com> wrote:
> So I'm in the process of Upgrading my servers from RHEL5 to RHEL6. On my
> RHEL5 system I had to build the reference policy from scratch in order to
> prevent users from being able to  transition to init_t through initrc_t.
> Basically, I want systems that have to be rebooted in order to restart
> certain services, like auditd, or at least be able to split those duties
> into different roles. One role can edit a file or install something, but a
> different role must restart it. Because life the universe and everything
> goes through initrc_t, just about anything on the system running as root
> can mess with services. I'd like to highly limit things, and
> haven't  really looked at any new developments in selinux for about 4
> years. What's the best way/place to start removing domain transitions and
> requiring additional roles.

When you are talking about "just about anything on the system running as root" 
are you referring to processes run as part of a system start script or a root 
login shell?

In the former case if you want to prevent the init.d script from daemon A from 
messing with daemon B (which is a real concern as some of the init.d scripts 
access data written by the daemon and could potentially be subverted) then one 
option would be to have the init.d script run in the context of the daemon.

In the latter case you could prevent a transition from sysadm_t to initrc_t 
without significant modifications to the policy, but you still need ways for 
the sysadm to restart daemons.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

--
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: Best base policy to use

[Jeremiah Jahn]

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

Thanks, this approach sounds pretty good to me.  On my last systems I used
an audit_admin and sec_admin, in addition to a number of other roles. I
looked VERY briefly at the mls policy, but I think it might be a little too
much for what I want, which is basically requiring 3 different roles to
manage a machine, and 3 additional roles to manage/use certain services.

semanage  makes persistent changes to a system, correct? I'm still uncertain
of the best way to modify a module, or at least make one less permissive.
would it be to remove or disable a module, get the source, modify it, rename
it, and then import it over the old one? for example lets say I didn't want
rpm_script_t to be able to transition into initrc_t, no matter what role it
started as. Or, I don't want the sysadm_t to be able to do both run_init_t
and rpm_t. Or am I completely in left field and not understanding the proper
use of roles?

On Wed, Jul 6, 2011 at 1:09 AM, Dominick Grift <domg472@gmail.com> wrote:

>
>
> On Tue, 2011-07-05 at 17:11 -0500, Jeremiah Jahn wrote:
> > So I'm in the process of Upgrading my servers from RHEL5 to RHEL6. On my
> > RHEL5 system I had to build the reference policy from scratch in order to
> > prevent users from being able to  transition to init_t through initrc_t.
> > Basically, I want systems that have to be rebooted in order to restart
> > certain services, like auditd, or at least be able to split those duties
> > into different roles. One role can edit a file or install something, but
> a
> > different role must restart it. Because life the universe and everything
> > goes through initrc_t, just about anything on the system running as root
> can
> > mess with services. I'd like to highly limit things, and haven't  really
> > looked at any new developments in selinux for about 4 years. What's the
> best
> > way/place to start removing domain transitions and requiring additional
> > roles.
>
> Main difference between el5 and el6 policy is that el6 policy is a
> hybrid policy of the old targeted and strict policy. (strict policy was
> merged into targeted policy)
>
> You  can now tune your policy to make it behave like the old strict
> policy by removing or disabling the unconfined and unconfineduser
> modules.
>
> In Redhat policy only unconfined_t can transition directly to initrc.
> Sysadm_t needs to use run_init to transition to initrc_t in the system_r
> role.
>
> el6 policy allows you to easily create new roles.
>
> So what you could do in my view is, disable or remove both unconfined
> and unconfineduser modules and then create your own roles, selinux user
> identities and logins.
>

> In that regard el6 policy has pretty much the same properties as current
> reference policy.
>
> > thanks,
> > -jj-
>

[-- Attachment #2: Type: text/html, Size: 3404 bytes --]

Re: Best base policy to use

[Dominick Grift]

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



On Wed, 2011-07-06 at 08:59 -0500, Jeremiah Jahn wrote:
> semanage  makes persistent changes to a system, correct? 

correct

> I'm still uncertain of the best way to modify a module, or at least
> make one less permissive. would it be to remove or disable a module,
> get the source, modify it, rename it, and then import it over the old
> one? 

That is one way yes but some modules depend on other modules so it may
get a bit more complicated than that.

Generally it becomes harder to maintain.

See my suggestion below

> for example lets say I didn't want rpm_script_t to be able to
> transition into initrc_t, no matter what role it started as. Or, I
> don't want the sysadm_t to be able to do both run_init_t and rpm_t. Or
> am I completely in left field and not understanding the proper use of
> roles?

No, you can achieve that by editing the policy i believe.

I would probably fork selinux policy. El6 policy does not get much
significant updates so merging changes into your fork should not be too
much work (as opposed to Fedora)


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

Re: Best base policy to use

[Jeremiah Jahn]

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

On Wed, Jul 6, 2011 at 3:10 AM, Russell Coker <russell@coker.com.au> wrote:

> On Wed, 6 Jul 2011, Jeremiah Jahn <jeremiah@goodinassociates.com> wrote:
> > So I'm in the process of Upgrading my servers from RHEL5 to RHEL6. On my
> > RHEL5 system I had to build the reference policy from scratch in order to
> > prevent users from being able to  transition to init_t through initrc_t.
> > Basically, I want systems that have to be rebooted in order to restart
> > certain services, like auditd, or at least be able to split those duties
> > into different roles. One role can edit a file or install something, but
> a
> > different role must restart it. Because life the universe and everything
> > goes through initrc_t, just about anything on the system running as root
> > can mess with services. I'd like to highly limit things, and
> > haven't  really looked at any new developments in selinux for about 4
> > years. What's the best way/place to start removing domain transitions and
> > requiring additional roles.
>
> When you are talking about "just about anything on the system running as
> root"
> are you referring to processes run as part of a system start script or a
> root
> login shell?
>

rpm script, when battening down the hatches on EL5 most of the modules could
be changed fairly easy to handle an auditadm, secadm, sysadm in the ref
policy, but it was a pain to limit sysadm due to it being able to transition
to both rpm_t AND initrc_t, because if you can get to one, you can get to
the other. My question is really what is the best way to remove transitions
without trying to build the policy from modified source. The old ref policy
wasn't quite strict enough. My EL5 systems are so locked down, the services
cannot be restarted without a reboot from the physical console and some usb
drives. It takes 3 people to do anything. It's rough, but we sleep pretty
well at night.


>
> In the former case if you want to prevent the init.d script from daemon A
> from
> messing with daemon B (which is a real concern as some of the init.d
> scripts
> access data written by the daemon and could potentially be subverted) then
> one
> option would be to have the init.d script run in the context of the daemon.
>
> In the latter case you could prevent a transition from sysadm_t to initrc_t
> without significant modifications to the policy, but you still need ways
> for
> the sysadm to restart daemons.
>




>
> --
> My Main Blog         http://etbe.coker.com.au/
> My Documents Blog    http://doc.coker.com.au/
>

[-- Attachment #2: Type: text/html, Size: 3502 bytes --]

Re: Best base policy to use

[Jeremiah Jahn]

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

On Wed, Jul 6, 2011 at 9:11 AM, Dominick Grift <domg472@gmail.com> wrote:

>
>
> On Wed, 2011-07-06 at 08:59 -0500, Jeremiah Jahn wrote:
> > semanage  makes persistent changes to a system, correct?
>
> correct
>
> > I'm still uncertain of the best way to modify a module, or at least
> > make one less permissive. would it be to remove or disable a module,
> > get the source, modify it, rename it, and then import it over the old
> > one?
>
> That is one way yes but some modules depend on other modules so it may
> get a bit more complicated than that.
>
> Generally it becomes harder to maintain.
>
> See my suggestion below
>
> > for example lets say I didn't want rpm_script_t to be able to
> > transition into initrc_t, no matter what role it started as. Or, I
> > don't want the sysadm_t to be able to do both run_init_t and rpm_t. Or
> > am I completely in left field and not understanding the proper use of
> > roles?
>
> No, you can achieve that by editing the policy i believe.
>
> I would probably fork selinux policy. El6 policy does not get much
> significant updates so merging changes into your fork should not be too
> much work (as opposed to Fedora)
>

Thanks for the help, that's what I had to do with the old ref policy, I
guess I was just hoping I wouldn't have to do that again, because there was
some newfangled way.  :) Oh well, but thanks again for the help.

[-- Attachment #2: Type: text/html, Size: 1853 bytes --]

Re: Best base policy to use

[Christopher J. PeBenito]

On 07/07/11 09:46, Jeremiah Jahn wrote:
> On Wed, Jul 6, 2011 at 9:11 AM, Dominick Grift <domg472@gmail.com
> <mailto:domg472@gmail.com>> wrote:
[...]
>     On Wed, 2011-07-06 at 08:59 -0500, Jeremiah Jahn wrote:
>     > for example lets say I didn't want rpm_script_t to be able to
>     > transition into initrc_t, no matter what role it started as. Or, I
>     > don't want the sysadm_t to be able to do both run_init_t and rpm_t. Or
>     > am I completely in left field and not understanding the proper use of
>     > roles?
> 
>     No, you can achieve that by editing the policy i believe.
> 
>     I would probably fork selinux policy. El6 policy does not get much
>     significant updates so merging changes into your fork should not be too
>     much work (as opposed to Fedora)
> 
> 
> Thanks for the help, that's what I had to do with the old ref policy, I
> guess I was just hoping I wouldn't have to do that again, because there
> was some newfangled way.  :) Oh well, but thanks again for the help.

Thats one thing on my wish list for SELinux policy writing tools.  A
role-o-matic where you start out with a base role, and have a bunch of
check boxes for options as to what it can do.  I try to keep the useful
data in the Refpolicy's XML, but the tool itself is nonexistent.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

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