On 25 January 2016 at 08:02, bruce <badouglas@xxxxxxxxx> wrote: > Look. > > I fully get the need for security.. But if I can't get the security > working as it should, but I still need to build whatever the project > might be.. the project is going to get created. > > If running Selinux in permissive mode is enough, great, so be it. But > when it comes to policies, for differnt users, applications, > files,etc.. and the possiblity of screwing something up if you go > wrong, then you have a bit of an issue there... And you can't simpy > tell someone, "if you don't know what you're doing, don't mess with > linux!" Not going to happen.. > > But hey.. to each his/her own. > > My goal wasn't to start a war.. Lord knows there are plenty of those > on the 'net already! > > Thanks to all who've replied. > I think it's partly the direction you started from, which is expecting there's going to be a problem and planning to turn off SELinux to forestall it. You may run into problems, but these days they're not that hard to sort out. sealert is useful if do you think SELinux is preventing something running and then you can check what the context should be https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Fixing_Problems-Searching_For_and_Viewing_Denials.html If starting from nothing then it's probably easier to go from that direction than start from having it turned off and enabling it once everything is done. At that point if things stop working then finding out what the issue is is going to be harder. I think your original concern was you might have, "an instance that has problems". If you have ssh access or something then it's not going to go away due to SELinux. If your only access into the system is a web interface it's hosting then that could happen. What SELinux tries to do is constrain access by services to only the resources they need, whether that's files (for http servers for example) or types of memory access, in an attempt to limit the exposure to a compromised application. The fewer outside facing services you have the less exposed you are. If you needed to grant unrestricted access to a service that becomes compromised then you lost the game anyway, whether you did that by turning off SELinux or by granting that access to that context. But most of the time the default policies will do what you want and are trivial to apply if something goes wrong. You don't have to set them up yourself for users and applications. Tools like restorecon and fixfiles https://fedoraproject.org/wiki/SELinux/fixfiles can be used to apply labelling if you've ended up with files that don't have context. "ls -Z" will quickly tell you if your files are missing context. -- imalone http://ibmalone.blogspot.co.uk -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
