Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
it depends who's doing the understanding really. It's generally classed as an "advanced" subject, so compared to other areas, yes it's probably fair to say it's complicated.
If your looking to try to understand it, I think that Gentoo has some pretty good documentation with a good mix of both theory and practice. Link to enough reading material to keep you busy for a while.
You could try reading the relevant chapters here http://www.linuxtopia.org/online_boo...ion/index.html.
It certainly takes a while to get your head around, unless you are already familiar with the general concepts/theory.
RBAC has been used "forever" in some other universes.
SELinux is not hard to understand when it's working - just look at Fedora; these days most people probably don't even disable it, they don't even know it's there. But it can be a mongrel when it's not (working). Although as @John VV points out above, things is better these days. There are even tools that accept the error message and give you a proposed solution - which is generally pretty close to the mark.
SElinux is easy if you just want to protect services (for example apache).
You only need to give the correct context to the files/dirs and enable some booleans for using php db connects for example.
If you want to create own policies it might be more complex. But that is not the use for most users.
It is not nearly as difficult as it use to be. Get a copy of CENTOS or something like that and google around for some documentation and just play around with it. As another user said working with selinux with the services that it protects out of the box is pretty straightforward. Having to write your own custom policies can be tricky. You can always put selinux in permissive mode, see what get's blocked and figure out a policy rule from that.
The tools to manage selinux have improved significantly over the years.
IMHO, the part about how SELinux works is fairly straightforward. Contexts, booleans and such don't take much to understand.
The more complicated part, and I still haven't found a sufficient explanation for this, has more to do with how/when to create custom policies.
I have several servers that have had SELinux either Disabled or Permissive for a long time and now I'm trying to sift through the audit logs to make sure I don't break everything when I turn it on.
While it's easy enough to use commands like ausearch and audit2allow, the issue is whether or not some of the activity is SUPPOSED to be allowed and if it IS, then why is SELinux trying to block it? I haven't found a way to identify what the various things are trying to do in order to know whether it's supposed to be able to do that or not.
So, while SELinux is not very difficult or complex in one sense, it can be very complex in a completely different sense.
So, should I create a policy to allow this? Should I not audit this event at all? Will this break something if I set SELinux to Enforcing? I really don't know.
Last edited by dcarrington; 08-22-2012 at 04:13 PM.
Reason: Additional info
If you want the syscall to succeed, yes.
Would have been better if you would have started your own thread for your own questions BTW.
Quote:
Originally Posted by dcarrington
Should I not audit this event at all?
Not if you want to know if ifconfig_t tries to do something in the initrc_t context.
Quote:
Originally Posted by dcarrington
Will this break something if I set SELinux to Enforcing?
Audit2allow returns "allow ifconfig_t initrc_t:tcp_socket { read write };" meaning ifconfig socket calls would fail during system boot, that is processes started in the initrc_t context AFAIK.
The purpose of my post was not necessarily to get answers to this issue it was to help jokar, the original poster, by giving an example of how SELinux can be complicated in one sense and not that complicated in another sense. The questions were rhetorical and meant to simply make the point that these are the things that need to be considered. That is why I did not create my own post for this issue...I wasn't seeking a solution, just sharing what I have found to be somewhat challenging with regards to why/when/how to determine of custom policies are needed.
In hindsight, I can see why it might have been perceived as attempting to hijack the thread, but I wanted to clarify that.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.