HowTo: Appfirst with SELinux enabled

Posted on by

Ok, first off, I hate people that say “turn off SELinux”… man, those idiots might as well tell you to turn off your firewall and open up your servers to the world.

This sounds like a nice gesture but, in today’s internet, it’s a shortcut to online suicide.

Anyway, here’s a mini-howto on how to generate your appfirst policy. This might require that you do it yourself since you might have different plugins/modules/whatever configured.

Anyway, here it goes:

# install the nice tools you need
su -
yum install -y setools-console policycoreutils-python

# remove the selinux_chk from /etc/init.d/afcollector.
...

# clean your audit.log
cat /dev/null > /var/log/audit/audit.log

# start app first while selinux is active
service afcollector start

# wait for it to start and generate a few selinux warnings (and get denied)
...

# now, set enforce off
setenforce 0

# generate a good policy
cat /var/log/audit/audit.log | audit2allow -M appfirst

# activate it
semodule -i appfirst.pp

# set selinux up again
setenforce 1

# check for errors
seaudit-report /var/log/audit/audit.log

# done!

You can copy your appfirst.pp to all your servers. It’s untested but it has worked fine so far for me! ;)

I got this file. Please, comment on it.


# cat appfirst.te

module appfirst 1.0;

require {
type unconfined_t;
type initrc_state_t;
type consoletype_t;
type proc_t;
type user_tmpfs_t;
type systemd_passwd_agent_t;
class process execmem;
class shm { write unix_read getattr unix_write associate read };
class file { write getattr read open };
}

#============= consoletype_t ==============
allow consoletype_t initrc_state_t:file read;

#============= systemd_passwd_agent_t ==============
allow systemd_passwd_agent_t initrc_state_t:file { read getattr open };
allow systemd_passwd_agent_t proc_t:file { read getattr open };
allow systemd_passwd_agent_t self:process execmem;
allow systemd_passwd_agent_t unconfined_t:shm { write unix_read getattr unix_write associate read };
allow systemd_passwd_agent_t user_tmpfs_t:file { read write };

-- end of file; don't copy this --

p.s. never turn off SELinux; that’s major idiot’s way!

13 thoughts on “HowTo: Appfirst with SELinux enabled”

  1. Thanks for calling me an idiot. I still going to turn off SELinux. You don’t explain why I should do any of these steps, e.g. why should I remove selinux_chk from afcollector? Or why nuking my whole audit.log should be a good idea. SELinux might be great, but it’s lacking good tutorials und GUI tools. And blindly following guides that you don’t understand is just as bad as disabling SELinux. You Barnes you System eben more, because of imagined security.

    Reply ↓

  4. Hey Chris, I’m pretty sure I was one of those idiots too ;)

    Renich, thanks for creating this solution for us. We’re going to try and duplicate what you did so we can support SELinux without turning it off. We’ll keep you posted with our progress.

    - Steve

    Reply ↓

  5. Perhaps if the idiots who designed selinux wrote human-readable documentation for managing it, other idiots wouldn’t end up throwing their hands in the air and disabling it.

    Reply ↓

  6. I have 15 years of experience in Linux, specialized in RPM distros (RH/CentOS) and yet I disable Selinux most of the time because its just a hell to maintain it. Time/effort is just not worth it for the security advantages it gives.

    Even if you get it to work, later in the future you do/install something new on the server it can create so much headache. Its like programming websites with cache enabled. Only when I am certain the server is only doing the same task for the rest of its life I will enable selinux.

    There are much easier ways to harden a server than SELinux. I admin over thousands of servers in my life, 99% of them were SElinux disabled. Not once someone got on my servers.

    Reply ↓

    • I beg to differ. Honestly, when you get the hang of semanage and the plethora of tools made available by the SELinux team, it’s quite easy to maintain.

      Security is always worth the effort in my sometimes humble opinion. One just needs to take the time to learn.

      Well, headaches come if you’re not well organized. I maintain a server with 400 websites and SELinux enabled. I never have any problems there, nowadays. To be fair, it took some time for the devs to adapt to the new security conventions; like:

      - Always put files to be written out of the document root and in a folder made for it; with a label like: httpd_sys_rw_content_t

      - If configs are to be modified by the server, put them in a “config” directory, outside doc root as well.

      Things like these… is that too difficult?

      In the end, it’s not about easiness; but effectiveness. That’s all that matters.

      You say that you’ve never been hacked (that you know of…). I congratulate you for your experience. I would, need some proof of your word and a certificate of “never hacked” though.

      In any case, I don’t believe SELinux is there to harm you. If you use it right, you can always prevent not only hostile takeovers, but further damage when hacked or injected.

      Reply ↓

Leave a Reply