HN2new | past | comments | ask | show | jobs | submitlogin

I want to, but this article was not enough. Say I have my own binary running as a service, and it has to do these things. What do I do? This article seems to be geared specifically towards nginx/a httpd.

I should probably just read the manpages.



Unfortunately, this is an area that could use some work. Tools for writing new policies are a long way away from what they could/should be. If you need something to work with SELinux that doesn't come with a policy you have essentially three options, in order of preference:

1) Develop a new policy from scratch. This is fairly hard, and the tools, such as they are[0], are not great. There's a couple of good resources out there, including [1] which has some good examples, and Dan Walsh's blog [2].

2) Use audit2allow to generate a policy semi-automatically. The resultant policy won't be very clean, and will almost certainly be more permissive than it needs to be, but if 1) is too much work (and I wouldn't blame you for this), then this is the next best thing.

3) Run your binary in the unconfined domain (do something like chcon -t unconfined_exec_t /usr/local/bin/foo), but leave the rest of the system enforcing. This will mean your binary itself is able to do anything, but the rest of the system is still protected.

Oh, and if you haven't read it before, you should definitely check out [3](pdf).

0: http://oss.tresys.com/archive/slide.php 1: https://github.com/TresysTechnology/refpolicy/blob/master/po... 2: http://danwalsh.livejournal.com/ 3: https://people.redhat.com/duffy/selinux/selinux-coloring-boo...


Thanks, all of those links are very informative. Shame that it seems like quite a lot of work still to set up for my own applications.


audit2allow takes care of 90% of the work for you, the rest is removing extraneous permissions and defining file context's (fcontext) which is pretty simple.

Really, it's as simple as this, I swear:

1. Write an empty policy for your application, defining a type for your binary (myapp_exec_t) with no permissions at all. Label your binary with this using chcon.

2. Set SELinux in permissive mode, run your application through it's paces.

3. Run audit2allow to get a decent policy to start with

4. Figure out where your application stores data on disk, if at all. Create another type (myapp_t) and label those directories with it (you shouldn't be writing outside of these directories by default, if you allow it to be changed in a config file the administrator can label new directories with semanage), then grant your application access to this type. Also make sure the installed path of your binary is labeled with your myapp_exec_t type.

5. Clean up the messy policy that audit2allow created if so desired, it's likely more permissive than necessary and not overly pretty. This will become easier as you work with SELinux policies more.

6. You're done

This will be time consuming the first couple times you do it, but you'll get quicker at it over time like anything else.


> Say I have my own binary running as a service

The default SELinux policy is "targeted" - this means that is has to be enabled for each service you want to confine.

Unless you explicitly switch it on, your service will run just fine.


I know, but I imagine that you should switch it on for your own services.


Did you read all the way through? To where he says his next article will cover exactly that?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: