Re: Best base policy to use

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Wed, Jul 6, 2011 at 3:10 AM, Russell Coker <russell@xxxxxxxxxxxx> wrote:
On Wed, 6 Jul 2011, Jeremiah Jahn <jeremiah@xxxxxxxxxxxxxxxxxxxx> 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/


[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux