[Pulp-list] Pulp & SELinux
cperry at redhat.com
Mon Aug 1 19:48:09 UTC 2011
On 08/01/2011 03:30 PM, John Matthews wrote:
> ----- Original Message -----
>> On 08/01/2011 07:51 AM, John Matthews wrote:
>>> We've added SELinux rules for Pulp on Fedora and RHEL-6 (RHEL-5 is
>>> not supported). The rules are deployed as part of the rpm.
>>> The SELinux rules for the pulp module exist at: selinux/pulp.te
>>> We have a wiki page here that describes a process for updating the
>>> rules: https://fedorahosted.org/pulp/wiki/SELinux
>>> If you see any issues please let me know.
>>> Pulp-list mailing list
>>> Pulp-list at redhat.com
>> Hi guys,
>> Please take this as constructive feedback. I'd be happy to give
>> to guides/documents to help improve this - currently though I'm not
>> happy with this, I have no warm fuzzies.
>> Good point - you can run pulp with SELinux enabled, so better than
>> it disabled.
>> Bad point - we have achieved this be choosing to weaken the default
>> security policies shipped in RHEL 6.
>> Ugly points - reviewing:
>> - we give Apache the ability to execute anything within /tmp.
>> - we give Apache the ability to delete its own log files.
>> - we give Apache the ability to modify its own and anyone else's certs
>> - we give Apache the ability to connect to any TCP socket/port rather
>> than restrict to specific needed one.
>> So, I'm concerned - but glad we have taken these first steps. This
>> initial policy should be one to build upon. With a firm understanding
>> what pulp is and what is does and where on the OS pulp needs to do
>> things - you should and we need to start locking pulp down by code
>> modifications and specific SELinux rules written for pulps needs.
>> command line tool(s) which are confined that pulp calls vs pulp as an
>> apache process trying to read/write over the OS is needed. The
>> holes though walls put up by the SELinux policies which are in pulps
>> will just lead to someone looking for ways to exploit pulp down the
> Thank you for reviewing. This is my first attempt at SELinux rules, I am not surprised they can be improved :)
It reminds me of the very first cut I did 4+ yrs ago for Satellite
before we formally supported Satellite + SELinux. Then further cuts I
started to define new stuff and say that things could write to specific
locations if they were running in that confine area. This lead to kbase
article for 'informal/unsupported' support policies for Satellite &
SELinux on RHEL 4.
Jan P for RHEL 5 & 6 built a lot more solid policy which is shipped and
now supported in Satellite. He has given presentations in the past on
some of his learning experiences - feel free to use it as a quick start:
Typically, say pulp wants to log to /var/log/pulp/ - rather than saying
apache can write to anywhere within /var/ you create a pulp context that
add ability to write to only this one additional location, vs opening up
the whole /var/.
Spacewalk example policy seen here:
In short, we define lots of new types and in general restrict to it.
Feel free to find me on IRC (I know you know where) :)
> I would be most interested in working with you to learn how we can improve the rules.
More information about the Pulp-list