[Pulp-list] Pulp & SELinux

Cliff Perry 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
>>> https://www.redhat.com/mailman/listinfo/pulp-list
>> Hi guys,
>> Please take this as constructive feedback. I'd be happy to give
>> pointers
>> 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
>> with
>> it disabled.
>> Bad point - we have achieved this be choosing to weaken the default
>> security policies shipped in RHEL 6.
>> Ugly points - reviewing:
>> http://git.fedorahosted.org/git/?p=pulp.git;a=blob_plain;f=selinux/pulp.te;hb=HEAD
>> - 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
>> of
>> 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.
>> Likely
>> 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
>> knocking
>> holes though walls put up by the SELinux policies which are in pulps
>> way
>> will just lead to someone looking for ways to exploit pulp down the
>> road.
>> Regards,
>> Cliff
> Cliff,
> 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 mailing list