alanr at unix.sh
Sun Jan 28 16:27:47 MST 2018
SE Linux will block certain kinds of attacks - depending on the
application and the attacker - that may help you -- or not.
Basically, *when configured correctly it will keep your application from
performing system calls it wouldn't normally perform*.
For example, it can block fork() calls ("popping a shell"), and it can
keep your application from opening files that it doesn't need to be able
to open to do its job. In a similar vein, it's also good at blocking
privilege escalation attacks (those where someone comes in, hacks some
app, then becomes root).
For it to do that - you have to make sure it knows how your application
normally works - and configure things accordingly.
On the other hand, if your application has legitimate access to
something your attacker wants to know, and it has a bug/hole such that
your attacker can force/fool your application into leaking it, it's
unlikely that SE Linux would be of help against this kind of attack.
And - to your original question... If it blocks an attack, the chances
are good that an average IT organization won't realize it - because the
average IT organization does a poor job of watching logs and knowing
what the logs mean ;-).
If you already have perfect applications with zero holes, and you run on
an OS with zero holes, and use libraries with zero holes, then it will
be of zero benefit to run under SE Linux ;-)
* Does it have a strange (non-traditional) terminology and view of the
* Does it have to be configured correctly to get you benefits
from it? Yes
* Can it be frustrating until you learn to deal with it? Yes
* Does it add work - sometimes quite a bit? Yes
* Do many people disable it rather than learn it? Yes
* Can it benefit you if you are willing to configure it
correctly? ProbablyIf you are running apps over which you have little or no control or
influence it can help you keep these apps from straying into doing
things they shouldn't...
You should compare the cost of configuring it to the cost of a breach of
the system under consideration. If this app has the "keys to the
kingdom" - such that you could go out of business if it's hacked - then
I'd think seriously about it.
alanr at unix.sh
On Sun, Jan 28, 2018, at 10:50 AM, Rob Nagler wrote:
> On Sat, Jan 27, 2018 at 5:40 PM, Alan Robertson wrote:
>> There was a server on the Internet that was completely open that no
>> one could become root on because of SELinux.>
> This statement may be true (no way to verify), but it's not saying
> anything useful. You don't need to be root to get all the data off of
> a server, which is probably all that's important. The Equifax hack,
> for example, was an exploit of Tomcat/Struts which was presumably
> running as user apache. If a server does anything useful (besides
> being a honey trap), and there is a bug one of its services (which had
> rights to read data, which all useful servers generally do), then
> SELinux is useless. SEL does not protect against intrusions, just
> I think SEL is misunderstood to the point that it is security
> theater. For example, the typical instruction for people "stuck" with
> SEL is to:>
> # grep some-service /var/log/audit/audit.log | audit2allow -M some-
> # service> # semodule -i some-service.pp
> At that point, you have "fixed" SEL, but what that means, you have no
> idea. Consider the nginx case a while ago, I wanted to open port 7000
> so I did the above magic, and realized that it enabled
> "gatekeeper_port_t", which I would have thought was port 7000, but it
> isn't. It's two tcp and two UDP ports:>
> # semanage port -l | grep gatekeeper
> gatekeeper_port_t tcp 1721, 7000
> gatekeeper_port_t udp 1718, 1719
> Now, if you don't know better, you've just enabled some ports, which
> may or may not matter. If I was relying on SEL (instead of iptables),
> then I would have created a potential vulnerability. Do you know what
> port 1718, 1719, and 1721 do? Me either.>
> Web Page: http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: irc.hackingsociety.org port=6667
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the LUG