Jump to content

kryptus

Members
  • Content Count

    1
  • Joined

  • Last visited

  1. I would recommend a day or two of practice with audit2allow in permissive mode, just so you get used to it, and after that it will be easy for you to manage policies etc... Your options pretty much like this: (use permissive for practice, even though it doesn't "deny" it still prints denials, so commands below will work just as good (memorize necessary policies)) # audit2allow -w -a <-- this command will tell you in a human-readable format what has been denied (you are going to use this, a lot)...when you're enforcing, a lot of stuff is going to be denied, like xorg stuff + ip/net stuff (of course) # audit2allow -a <-- this command will print a so-called "type-enforcement rule" # audit2allow -a -M somepolicy <-- Now this is your way around...the output of the audit2allow -a command will now be stored in a somepolicy.pp file (you can use any file name you like, instead of <somepolicy>) # semodule -i mypolicy.pp <-- This is how you install your custom modules, and everything that audit2allow -a has logged as denied will now be allowed NOTE: This is a bad practice in reality (production environment), you should never allow ALL denied services, but for practice it's perfectly fine. I think the policies you make in permissive mode remain across boots/type changes... Let me know how it went, and... Good luck! P.S. Here are some links you might find useful: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Fixing_Problems-Allowing_Access_audit2allow.html https://wiki.centos.org/HowTos/SELinux http://danwalsh.livejournal.com/24750.html
×
×
  • Create New...