4 ms·
When CentOS 7 came out, I decided to make peace with all of the new stuff (systemd) and all of the old stuff I had been disabling (SELinux.) Turns out that doi
by greglindahl 10y ago
When CentOS 7 came out, I decided to make peace with all of the new stuff (systemd) and all of the old stuff I had been disabling (SELinux.)
Turns out that doing crazy shit like letting users have their html files in ~/public_html/ requires a lot of SELinux configuration. procmail touching user directories? Yep. spamassassin? Why, yes. Maybe there's something I did wrong... I did read the docs.
Also turns out that there isn't a tool which tells you what new rules are needed, relative to the existing configuration, for recent SELinux denies. Yeah, there are some tools to spit out a complete config file based on all logged problems, but not a diff, and I had already lost some of the early logs to logrotate n=4 by the time I realized I needed 'em.
111 lines of perl and 116 lines of SELinux rules later, I was in good shape. But REALLY? REALLY?
- protomyth 10y agoThe truly scary part for me is that I might have missed one little thing that will come back and bite me. I have two RedHat boxes because a vendor requires them for software[1]. Luckily, neither needs to service internet clients. 1) the same vendor that feels a 752 Mbyte SQL file constitutes a patch
- greglindahl 10y agoThe server I'm talking about is a multi-user box used by a bunch of people for various toy activities. So what usually happens is someone will try to install something new and reasonable, it will fail, they will bitch at me, and then I'll run my scripts and update the selinux config. However, I do end up with surprising mystery issues. Just got a rule for logrotate needing to be able to reload some daemon... a year into this experiment. Wut?
- protomyth 10y agoThankfully, my servers are in full appliance mode and I don't have to worry about users (they are on the FreeBSD / ZFS box or one of the OpenBSD machines). I still worry since they have pretty valuable data on them.
- andrey_utkin 10y ago> Turns out that doing crazy shit like letting users have their html files in ~/public_html/ requires a lot of SELinux configuration I guess "setsebool httpd_enable_homedirs on" would do that. > Also turns out that there isn't a tool which tells you what new rules are needed, relative to the existing configuration, for recent SELinux denies setroubleshoot should be shipped with RedHat-based distros. Mentioned in https://youtu.be/cNoVgDqqJmM https://youtu.be/cNoVgDqqJmM Besides that, there's domain-based switch-off command, "semanage permissive --add programname_t" > 111 lines of perl and 116 lines of SELinux rules later, I was in good shape. I paid a SELinux developer and just nice guy from #gentoo-hardened, perfinion, to help me with setting up my workstations so that I could run untrusted crap like skype in enforced mode. After that, I was in good shape and full of warm cozy safe feeling. And now I can use SELinux hardening stuff at my job.
- dice 10y agoThe targeted policies and functionality booleans in CentOS are really nice. I took the same step with finally buckling down and actually using SELinux for version 6 and there was definitely a learning cliff, but just like anything else after you've used it for a while it's all old hat. You may have seen it already, but the CentOS SELinux HOWTO was very useful for me in learning how to interact with it: https://wiki.centos.org/HowTos/SELinux https://wiki.centos.org/HowTos/SELinux >Turns out that doing crazy shit like letting users have their html files in ~/public_html/ requires a lot of SELinux configuration You should just be able to `setsebool httpd_enable_homedirs on`. What trouble did you run in to? >procmail touching user directories? This works by default for me in in C6 and C7: I'm using it on a number of production systems. The ~/.procmailrc should have type procmail_home_t but procmail itself can create/modify/delete files in the user's home dir. >spamassassin? Again, should just work. You may need to `setsebool spamassassin_can_network on` depending on configuration. >a tool which tells you what new rules are needed That would be nice. My usual process if I'm in a situation that needs custom rules is to: echo '' >/var/log/audit/audit.log # (it would be better to rotate it here, but you get the idea) setenforce 0 # Do whatever I want to be able to do... setenforce 1 sealert -a /var/log/audit/audit.log
- greglindahl 10y agoI read that HOWTO, actually, and the stuff you're describing isn't really explained in it. For example, there's a httpd example changing a label right there in the HOWTO, and it doesn't explain where I'm supposed to discover the correct label. And the recommended audit-script-to-config doesn't show the correct labels, it prompts you to relax the rule instead of changing labels. My procmail rules don't correspond to what you said procmail does. And how was I supposed to discover procmail_home_t ? I'm not saying I'm Mr. Super Smart, I'm just saying that it's quite a bit of investment.
- jamble 10y ago> I read that HOWTO, actually, and the stuff you're describing isn't really explained in it. Did you read this part? It explains a solution to your first gripe: https://wiki.centos.org/HowTos/SELinux#head-0f6390ddacfab39ee973ed8018a32212c2a02199 https://wiki.centos.org/HowTos/SELinux#head-0f6390ddacfab39e... I find audit2why helpful, as well as semanage boolean -l, semanage user -l, semanage fcontext -l. Often times more than not, these tools either help me fix an 'audit' issue or point me in the right direction. Check them out sometime, if you don't want to go digging through docs or serverfault - the labels tend to be generally straight forward IMO :-)
- drauh 10y agoYeah, I was seriously ready to destroy furniture when I had to do it for a nonstandard software installation at work, a few years ago. I had to do a crapload of ausearch and audit2allow, and I possibly ended up with a too-permissive rule set. Who knows?