3 ms·
I severely wish for SELinux to have better documentation. I can and I have worked myself into dense and hard topics with little documentation, but SELinux is it
by tetha 5y ago
I severely wish for SELinux to have better documentation. I can and I have worked myself into dense and hard topics with little documentation, but SELinux is it's own thing. I can totally see how SELinux could improve the security of all our custom application servers a lot, and I think that's the case for pretty much all custom aplication servers - but it has taken months of thinking, reading sparse documentation, thinking about my linux knowledge to get some faint idea of how to implement a policy for a service. however, that's far from where I'd be confident to start this as an actual project.
Given recent redhat stunts and our current infra switch, I hope AppArmor is less dense, or at least equipped with more approachable documentation.
- z3t4 5y agoAlot can be done with SystemD (sandboxing)
- z3t4 5y agoApparmor has a nice learning curve, it's easy to get started with: sudo apt install apparmor-utils sudo aa-genprof /path/to/app Profiles are saved in /etc/apparmor.d/ Many apps need access to /dev/urandom, /usr/bin, /usr/lib and be able to send and receive hup and int signals from other programs. One nice thing is that you can define rules for child process spawned by your executable: /path/to/your/app/childprocessorscripts/** Cx -> scripts, profile scripts { ... } Unix sockets are very nice, prefer them over TCP/IP. For example if you have Nginx or other proxy, use Unix sockets instead of TCP/IP! network unix, Unix sockets allows you to set permissions per socket If your app needs to spawn something that use TCP: /usr/bin/curl px -> networkTool, profile networkTool { network, } Permission errors will show up in /var/log/kern.log You can find errors and edit profiles with aa-logprof If you get frustrated you can allow everything, but show logs: sudo aa-complain /path/to/app