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

Re: [Pulp-list] Pulp & SELinux

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

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