Your visual how-to guide for SELinux policy enforcement (opensource.com)

[Posted November 14, 2013 by jake]

Over at opensource.com, SELinux hacker Dan Walsh describes SELinux policy enforcement using dogs and cats. It has lots of cute cartoons (by Máirín Duffy) of the interaction between various types of dogs, a cat, food meant for each, and Tux as an enforcer of the food policies. It looks at type enforcement (TE), multi-category security (MCS), and multi-level security (MLS) using dog/cat analogies as well as relating them to the "real world". "SElinux is a labeling system. Every process has a label. Every file/directory object in the operating system has a label. Even network ports, devices, and potentially hostnames have labels assigned to them. We write rules to control the access of a process label to an a object label like a file. We call this policy. The kernel enforces the rules."

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 14, 2013 20:42 UTC (Thu) by NightMonkey (subscriber, #23051) [Link] (43 responses)

As an admin, I turn off SELinux everywhere I can. In my experience, it is overengineered, improbable to administrate, a giant time sink, and has created more problems (and a false sense of security from becoming just a buzzword to check off) than it solved. Like replacing a heavy door with a good solid lock with no door and a jumbled pile of hundreds of locks on the floor.

Ever since I saw it just slam a NAS farm via shared NFS mounts with its lumbering scans after a ruleset upgrade, no more, said I.

Or maybe that's just me, or maybe there are places that really, really use it and would be lost without it. But I don't want it to be enabled by default. Ever.

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 14, 2013 21:10 UTC (Thu) by Henning (subscriber, #37195) [Link] (39 responses)

As an admin, I turn on SELinux everywhere I can.
In my experience it is very good at catching cases where the setup has not been thought out or where people try to do odd things which preferably should be done other ways (like working as root when you deal with user-content).

I can feel that it does force you to do it the Red Hat way (I have not tried the policies of other distros to know how they work) or you will be forced to deal with special written policies and exceptions, but that is for me a small price to pay to unify administration and setup.
By enforcing everything to be done in certain ways helps me enforce security policies and helps a lot in documentation.

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 14, 2013 21:51 UTC (Thu) by NightMonkey (subscriber, #23051) [Link] (16 responses)

But what about when the setup of SELinux hasn't been thought out? Why dedicate time to setting up SELinux to catch bad setups rather than just fixing the setups that are bad? :)

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 14, 2013 22:10 UTC (Thu) by raven667 (subscriber, #5198) [Link] (11 responses)

I too leave SELinux on by default on my RHEL5/6 systems and have only needed to touch the policy a handful of times. It's thought out and fully configured out of the box, you don't have to dedicate time to setting it up. if you are running your own locally generated software that presumably doesn't include a policy then it runs as an unconfined user and SELinux is pretty much a non-factor.

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 15, 2013 2:40 UTC (Fri) by dlang (guest, #313) [Link] (2 responses)

the question is if SELinux actually provides any real protection in situations like yours.

the default RHEL policies cause so few problems because they enforce so little. (note that this is after they were opened repeatedly because the tighter limits did cause grief)

If your custom apps aren't affected by SELinux, then does it really help? in a reasonable network setup, the only thing that the outside world should be able to get at is your custom app, and if it's running as an unconfined user, so will any exploits that get sent to your app.

For a LSM, you really need something that a good admin can use to lock down your custom app without going crazy. SELinux doesn't seem to be meeting this requirement.

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 15, 2013 3:21 UTC (Fri) by raven667 (subscriber, #5198) [Link] (1 responses)

In my case the custom apps are usually run behind a web server which is constrained by policy, as well as its child processes. The benefit is that web application exploits which can be used to upload code or run commands are much harder to execute which mitigates a bunch of risk. Sure if someone is able to inject code into the daemon and run a local kernel exploit with the interfaces which are not filtered away from the daemon then they can do anything but there is no security technology which can prevent that from happening.

The pre-built policies are comprehensive, covering most or all of the daemons and software which comes with the system. Of course if you don't have a policy for your custom application then this doesn't provide a benefit, but it also isn't a hindrance which was the main point. You can write a policy for your in-house apps if you want and take advantage and they are complicated because they are comprehensive and fine grained. I don't think that another system with the same comprehensive fine grained control would be any less complicated, just different, so this kind of sandboxing does require effort and attention to detail.

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 16, 2013 14:31 UTC (Sat) by PaXTeam (guest, #24616) [Link]

> Sure if someone is able to [...] run a local kernel exploit [...] then
> they can do anything but there is no security technology which can
> prevent that from happening.

fortunately there is, available for over a decade now :).

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 15, 2013 14:07 UTC (Fri) by epa (subscriber, #39769) [Link] (7 responses)

For me the biggest problem with SELinux is lack of transparency in error messages and in what other parts of the system report. For example you may get a 'permission denied' error reading a file. So you chmod a+r it. Still permission denied. Of course, the error message doesn't give you any hint of *why* the permission was denied (which is mostly the fault of the single integer 'errno' that has to stand in for a detailed message - Plan 9's 'errstr' is far superior).

So to check the permissions you 'ls -l' the file. That shows it readable. This is all most confusing unless you know in advance to look out for SELinux. If SELinux is to be turned on by default, then for sanity:

- error messages should give useful information, not just stock error strings (and yes I know that replacing the ancient errno mechanism will be a big job, but it is decades overdue). And no, some weird GUI thing that floats up alerts over your desktop is not an acceptable substitute.

- classic Unix permission tools such as chmod need to be SELinux-aware. If you ask for 'a+r' (readable by all) then it should either give you that, modifying the SELinux policies if necessary, or give a warning that 'readable by all' is not a possible setting for this file.

- and of course, tools that report permissions such as ls must report SELinux settings that affect those permissions, as far as is possible.

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 15, 2013 15:32 UTC (Fri) by raven667 (subscriber, #5198) [Link] (6 responses)

> and of course, tools that report permissions such as ls must report SELinux settings that affect those permissions, as far as is possible.

This part is done, tools like ls, ps, etc. support the -Z option which shows SELinux types

> error messages should give useful information

As you point out that is a system wide inheritance from UNIX and may be very difficult or impossible to change while maintaining compatibility with the last 30yrs of already written software. I dunno. There is a utility, selinux-troubleshooter, which should probably be running by default on any enforcing system not just GUI ones, which reads the audit logs and writes out human readable error messages to syslog.

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 15, 2013 18:51 UTC (Fri) by epa (subscriber, #39769) [Link] (3 responses)

Plan 9 provides a new errstr while continuing to set the existing errno. That is one obvious way to proceed.

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 15, 2013 23:54 UTC (Fri) by nix (subscriber, #2304) [Link] (2 responses)

Of course, the problem with errstr is that now you have to translate it. That is, translate a string freely composed by the kernel. I guess it would have to look at the locale of the user program and grow an in-kernel gettext implementation, or call back into it to do the translation, or something... (or, I suppose, have glibc do the translation automatically. After all, it sets errno automatically now: the kernel knows nothing about it, it only knows about small negative return values.)

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 16, 2013 2:59 UTC (Sat) by robertm (subscriber, #20200) [Link]

Strings are great if the only thing you ever want to do with errors is display them to the user, but if you want your program to do anything else in response you're really looking at some kind of struct getting passed back from the kernel to userspace. At least that moves the issue of generating a translatable human-readable string back into userspace, but probably causes quite a few issues for the syscall interface.

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 16, 2013 9:13 UTC (Sat) by epa (subscriber, #39769) [Link]

Of course, the problem with errstr is that now you have to translate it.

While user-facing error messages should of course be translated, I think this is a false consideration for system-call-level errors. They do not need to be translated any more than open() needs to be renamed abrir(). The existing errno is still there, and can be looked up in translation tables as before; then the full errstr is available for more technical reporting of what went wrong. If you do not speak English you are unlikely to understand SELinux configuration either.

While it would be great to have a carefully specified 'error struct' with inheritance hierarchies, template-based localization and all the rest, that is icing on the cake compared to the basic task of getting some more useful information into error messages. Let's not let the best be the enemy of the good.

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 16, 2013 9:02 UTC (Sat) by oldtomas (guest, #72579) [Link] (1 responses)

> This part is done, tools like ls, ps, etc. support the -Z option which shows SELinux types

Thus rendering lots of little utils binary-dependent on some obscure libselinux. Thanks for reminding us of that.

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Dec 8, 2013 16:40 UTC (Sun) by nix (subscriber, #2304) [Link]

You can compile all those tools without libselinux support, if you want to, and -Z quietly vanishes away. Awful world-ending dependency this is not.

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 14, 2013 22:27 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

If we could know in advance all the things that are wrong, we wouldn't need additional security measures in the first place but it is naive to think that anything really works well that way. A recent adoption of SELinux is in Android (albeit in permissive mode for now though Samsung is apparently enforcing it already)

http://source.android.com/devices/tech/security/enhanceme...

If you are running Fedora or RHEL where there is a well tested and extremely well maintained set of SELinux policies, there aren't many reasons to go out of your way to turn it off when it is possible to tweak policies or run specific daemons in a unconfined manner as a incremental step towards full enforcement.

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 15, 2013 3:40 UTC (Fri) by duffy (guest, #31787) [Link] (1 responses)

FWIW Samsung is enforcing on the Galaxy S4... my phone says it is anyway, and I got an OTA SELinux policy update today.

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 15, 2013 4:11 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]

Thanks for the confirmation! Apparently Android 4.4 devices are in enforcing mode by default and FORTIFY_SOURCE as well

http://source.android.com/devices/tech/security/enhanceme...

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 14, 2013 22:35 UTC (Thu) by Henning (subscriber, #37195) [Link]

In my experience, there is no big amount amount of time needed to set SELinux up. It is on by default and will not interfere in my daily routines or in any standard software install. I have also seldom felt that SELinux policies are incorrect and, in the few cases they have been problematic, it has been a small task to research and implement a workaround.
There might be some knobs you have to hit or some special directory labling you have to define as part of installing a certain software (for example a ftp server), but that is very little time spent on SELinux in comparison with the time spent on configuring the rest of the solution and making it secure.
SELinux helps me making sure that everything is working as intended and helps detect corner cases or oddities that might have been flaws or issues not thought of when designing the solution and that is well worth the extra time on SELinux for the few cases when it is needed.

I can agree that poorly designed software can be problematic to lock down but then you almost always have the option of running it unconfined while letting the rest of the system to benefit from the extra layer of security.

But, to me, disabling SELinux as a solution is basically the same response as setting the file permissions to 777 when stumbling on a file access problem. It will solve the problem and no time is needed to research the it, but there is usually a better and more well confined solution.

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 15, 2013 4:03 UTC (Fri) by lamawithonel (subscriber, #86149) [Link] (21 responses)

The number of recent, highly publicized vulns which SELinux can mitigate is astounding. My only complaint is the userspace CLI. I would really like to see it unified into a smaller set of commands with a sub-command interface, like Git, iproute2, Puppet, Ganeti, etc. I think that would soften the learning curve, if only a little.

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 15, 2013 4:46 UTC (Fri) by NightMonkey (subscriber, #23051) [Link] (7 responses)

Astounding? Do you have links to some good examples?

Is SELinux the ONLY way to mitigate these vulnerabilities you reference? Would just updating the packages do the same?

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 15, 2013 5:29 UTC (Fri) by raven667 (subscriber, #5198) [Link]

Those are two different things, patching can help after the exploits are out in the wild, permissions help prevent the exploit you don't know about yet that isn't patched from having as much effect.

Why wouldn't you want to use all of the effective tools at your disposal, especially with no effort on your part?

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 15, 2013 9:12 UTC (Fri) by khim (subscriber, #9252) [Link] (5 responses)

Is SELinux the ONLY way to mitigate these vulnerabilities you reference? Would just updating the packages do the same?

Do you really think patches can affect systems where they are not installed yet but will be installed soon? Causality does not work this way.

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 15, 2013 19:08 UTC (Fri) by NightMonkey (subscriber, #23051) [Link] (4 responses)

A point of contention I have is that the time spent on implementing and utilizing SELinux would be better spent on making sure to update your systems daily or weekly, and crafting infrastructure to allow that update process to be non-disruptive (yay, uptime is LESS than 30 days!) and routine. Many of the arguments presented for SELinux assume that there is some intelligent and aware authority imposing a strict parsing of logs, and an organizational willingness to encourage and support sysadmins to investigate every alert line emitted by SELinux. This could be so in government, or in heavily regulated industries that require deep audits, but for smaller organizations, it just doesn't make sense.

Adding more noise doesn't help us be more secure. I believe that my time, in the environments that I support, is better spent taking packages out of the default install. The easiest software to administer is software that is never installed. :)

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 15, 2013 20:38 UTC (Fri) by FranTaylor (guest, #80190) [Link] (3 responses)

"that the time spent on implementing and utilizing SELinux would be better spent"

Yeah I need to get back the whole second I spent deciding whether or not to check selinux in the installer.

"and an organizational willingness to encourage and support sysadmins to investigate every alert line emitted by SELinux. "

Yeah I also need to get back all the time I've spent (none!) looking over all those logs in all the systems where I've enabled selinux, because the bugs that happen on my machine don't ever happen on any other machine and there is no chance that any redhat engineer will ever find it.

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 16, 2013 22:42 UTC (Sat) by pboddie (guest, #50784) [Link] (2 responses)

If SELinux works perfectly then it is obviously nice to have, and I've managed to set things up to work with SELinux before now without tripping up too much.

It's a harder sell when you have people being pestered by dialogues on their desktop about something linking to zlib in the wrong way, where they have no idea how it is being caused, no idea how to avoid it, and no means of stopping it or turning the dialogues off. I remember this "fondly" from RHEL a couple of releases back.

Sometimes I think that the "feature" of RHEL to shove dialogues in unprivileged users' faces is some kind of teaser: here's what you could do if you were root. New updates available? Sorry, you can't do that! Please don't press this button again. To be fair, I do wonder whether other distributions check to see whether a user could elevate their privileges before dangling such things in front of them.

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 17, 2013 17:01 UTC (Sun) by apoelstra (subscriber, #75205) [Link] (1 responses)

> Sometimes I think that the "feature" of RHEL to shove dialogues in unprivileged users' faces is some kind of teaser: here's what you could do if you were root. New updates available? Sorry, you can't do that! Please don't press this button again. To be fair, I do wonder whether other distributions check to see whether a user could elevate their privileges before dangling such things in front of them.

Well, there is no way the OS can tell whether or not the human at the terminal knows the root password.

But I agree these messages are irritating when there's nothing you can do about them.

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 28, 2013 19:56 UTC (Thu) by Wol (subscriber, #4433) [Link]

Maybe check for group wheel (or equivalent?).

Cheers,
Wol

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 15, 2013 12:43 UTC (Fri) by spender (guest, #23067) [Link] (12 responses)

You are completely right. It's like I've always said to myself when writing kernel exploits:
"If it weren't for SELinux, this exploit would have worked!"

Oh wait, I've never said that.

http://www.youtube.com/watch?v=WI0FXZUsLuI
http://www.youtube.com/watch?v=EXDwyezuOOM
http://www.youtube.com/watch?v=jt81NvaOj5Y
http://www.youtube.com/watch?v=KvREwhfQmbc
http://www.youtube.com/watch?v=fUNE5t-bqsQ
http://www.youtube.com/watch?v=arAfIp7YzZ4
http://www.youtube.com/watch?v=iN1fdvktRbk
http://www.youtube.com/watch?v=UdkpJ13e6Z0

Please tell me how SELinux could prevent exploitation of the PERF_EVENTS vulnerability given that it has no control whatsoever over the perf_event_open syscall? How about vmsplice? Or perf_counter? Or move_pages? It matters not one whit how complex or supposedly "locked down" a policy is when the TCB is so wide open that the same exploitation techniques I used 6 years ago still work today.

Red Hat loves to promote this illusion: http://farm1.static.flickr.com/223/481929076_959cdef97d_o...
but this is the reality: http://grsecurity.net/~spender/pics/mac_security_sesamest...

I am so tired of this blind faith in SELinux created out of a combination of appeal to NSA authority/"expertise", the equivocation that if it's not bothering you that it's somehow enforcing secure policies (because it's SELinux after all!), the false belief that SELinux has full control over the system, and the complete ignorance of kernel exploits. Stupid cartoons and metaphors that abstract out the important details do nothing but promote fetishism of the technology.

-Brad

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 15, 2013 13:41 UTC (Fri) by rmayr (subscriber, #16880) [Link]

I think that the original comment was not towards alleviating kernel exploits, but that SELinux can help against userspace exploits - and that is something that still holds true. It is fairly clear that a mechanism implemented within the kernel will not be able to help against all exploits on the same level.

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 15, 2013 22:02 UTC (Fri) by walters (subscriber, #7396) [Link] (9 responses)

Hi Brad,

> Red Hat loves to promote this illusion

I work for Red Hat and have contributed to SELinux, and just for what it's worth, I completely agree that the kernel flaws diminish the value of SELinux (they also diminish the value of DAC, of course).

There are mitigations of course for some of them; userspace can make use of the seccomp mode 2 bits to disallow Apache access to perf for example.

But I think your rants about SELinux are misplaced; the exploitable holes don't exist *because* of SELinux in any way.

You maintain a number of out-of-tree patches, I know, but still: I think you'd find it a more rewarding use of time trying to figure out how to better prevent new API from being exploitable than ranting in an LWN comment.

For example, helping Dave Jones with on Trinity, joining in code review upstream, etc.

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 15, 2013 22:20 UTC (Fri) by NightMonkey (subscriber, #23051) [Link] (2 responses)

Classifying his comment as a "rant" is not merited, and doesn't represent RedHat well. I don't believe what he posted qualifies:

http://en.wiktionary.org/wiki/rant

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 15, 2013 22:24 UTC (Fri) by walters (subscriber, #7396) [Link]

Fair enough, I retract the use of the word "rant". (And will return to more productive work on userspace myself...)

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 15, 2013 22:35 UTC (Fri) by walters (subscriber, #7396) [Link]

> and doesn't represent RedHat well

And before I forget to say - I am certainly not speaking on behalf of Red Hat here in any way. I contributed to SELinux on my free time before working at Red Hat, and my response to Brad was from that perspective; I don't think a useful article on SELinux merited the *tone* of his response.

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 16, 2013 1:52 UTC (Sat) by spender (guest, #23067) [Link] (5 responses)

Hello,

> There are mitigations of course for some of them; userspace can make use of the seccomp mode 2 bits to disallow Apache access to perf for example.

What's Red Hat doing about it?

> But I think your rants about SELinux are misplaced; the exploitable holes don't exist *because* of SELinux in any way.

I guess if you don't count that whole thing about SELinux making otherwise unexploitable null ptr dereferences exploitable for a year or so (between RHEL 5.2 and 5.4):
https://access.redhat.com/site/articles/17995
Only fixed because of the release of one of my exploits, who knows how long it would have stayed exploitable otherwise.

The problem is you come here and give these token admissions about kernel vulnerabilities, but what is Red Hat doing about it other than fixing individual bugs after the fact? SELinux is your hammer and you consider everything in security to be nails. You can deny it all day, but it's evident from what Red Hat has produced in the past decade, what they keep presenting at each Linux Security Summit: SELinux, SELinux, SElinux, and the occasional poor NIH-version of techniques developed by others (often us). Red Hat lacks security vision -- there's no innovation going on and no proactive approach; it's a joke. It's even obvious from your final sentence that mimics what upstream thinks is best effort (https://www.youtube.com/watch?v=VDsHxJjvKSk&t=34m20s): the horribly buggy 1992AD-style fuzzer Trinity, auditing code, and source analyzers.

I've taken your message about finding more rewarding use of my time to heart, so I wanted to share this image with you from tonight regarding the non-existent security benefit of Red Hat's prized module signing enforcement (billed as some kind of rootkit defense since 2006 or so):
http://grsecurity.net/~spender/modulesigning.png

Thanks,
-Brad

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 21, 2013 20:37 UTC (Thu) by flewellyn (subscriber, #5047) [Link] (4 responses)

What is the contents of your module_signing_is_useless.sh script?

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Dec 3, 2013 19:53 UTC (Tue) by BenHutchings (subscriber, #37955) [Link] (3 responses)

Presumably something like:

addr="$(awk '$3 == "signedonly" { print $1 }' /proc/kallsyms)"
# exploit bug to write 0 to $addr

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Dec 3, 2013 20:02 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (2 responses)

You don't need a bug. There's plenty of ways to modify kernel memory if you're root.

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Dec 3, 2013 20:40 UTC (Tue) by BenHutchings (subscriber, #37955) [Link] (1 responses)

I was assuming a generic script. Given CONFIG_DEVKMEM is disabled, I think all the methods you've identified involve firmware or peripheral DMA masters. Are there generic ACPI methods that can be used for this?

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Dec 3, 2013 21:00 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

kexec's an obvious one.

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 15, 2013 22:09 UTC (Fri) by deepfire (guest, #26138) [Link]

How many kernel exploits have there been for RHEL6 -based distros?

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 14, 2013 22:02 UTC (Thu) by rwmj (subscriber, #5474) [Link]

I think you are foolish to turn SELinux off except in the most exceptional of cases. It just works and has negligible impact, but there are tremendous security benefits to confining daemons.

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 14, 2013 22:14 UTC (Thu) by raven667 (subscriber, #5198) [Link] (1 responses)

> slam a NAS farm via shared NFS mounts with its lumbering scans after a ruleset upgrade

Anything that recurses through a directory tree looking at the file metadata is going to have that effect, there isn't anything the tool is doing wrong, find / -ls would do the same thing.

Your visual how-to guide for SELinux policy enforcement (opensource.com)

Posted Nov 17, 2013 21:06 UTC (Sun) by k8to (guest, #15413) [Link]

There's a legitimate difference between a pattern that can be used to break a system, vs a system that gets broken automatically, vs a system that requires you to break it.