5 ms·
It is interesting that the malware hijacks ssh as well. This make me think that RHEL's approach to confining services using SELinux is a good idea, although it
by betterunix 14y ago
It is interesting that the malware hijacks ssh as well. This make me think that RHEL's approach to confining services using SELinux is a good idea, although it is possible that this malware also exploits some weakness there.
- astrodust 14y agoIf SElinux actually made sense to mortals it might be more widely used. It's dizzyingly complicated to configure correctly.
- TallGuyShort 14y agoI've also lost count of the number of times the solution to some problem was to disable SELinux because we can't make it work any other way.
- noonespecial 14y agoThe worst part of SELinux is that it seem to just silently prevent things from working. The entry in its cryptic little log will have almost nothing to do with what didn't work. If the system acts weird, its either rooted or SELinux is on.
- betterunix 14y agoSure, but I think Red Hat has done a good job of simplifying things -- the SELinux booleans are pretty straightforward (e.g. "httpd_execmem" is probably something you want to keep off), the included users/roles are fairly useful, and the labels more or less make sense. For desktops, the sandbox tool is pretty handy. If you need something more complicated, I can see it being difficult (having sweated through the process myself).
- astrodust 14y agoIf you say something like "httpd_execmem" you've already lost me. That is not straight-forward, that's Byzantine. RedHat has tried to make this thing more usable, but it's still a greasy pig to wrestle. Applications just mysteriously "don't work" without explanation, and there's no obvious resolution to the problem. Although iptables is an example of an ornery configuration format, at least it's self-contained. SELinux seems to allow applications to define their own quirky rulesets which complicates things severely.
- druiid 14y agoThere will always be an explanation. Anything that 'pings' selinux is logged to audit.log. It might be difficult to decipher some of the rules being hit, but it's easy enough to work around them without disabling selinux wholesale. Look into audit2allow. It makes things MUCH simpler.
- druiid 14y agoHonestly I think this isn't true at this point. It's pretty damn easy with 'audit2allow' (That's a console command) and your audit.log, to fix for just about any issues you have getting your applications working with selinux. What's better still, is there are a couple selinux modules for Puppet or Chef which allow you to take your audit2allow rules and build them on the fly for any deployed machine!
- rlpb 14y agoTake a look at AppArmor. It's much simpler since it's based on executable paths instead of metadata attached to executables at filesystem level. Ubuntu uses it.
- cafard 14y agoIt is a pain. However, it can be used, provided that one has the patience to keep tweaking and examining the logs.
- marcosdumay 14y agoFor replacing ssh they need a priviledge escalation anyway, and after such escalation SELinux makes no difference. Unless, of course, you run apache as root. Bu then, SELinux won't protect you either.
- betterunix 14y agoActually, SELinux can confine the root user. That said, while kernel exploits will not be stopped by SELinux, there are various other privilege escalation attacks that might be. Brute forcing the root password, exploits in other system processes (maybe even SSH itself), bad (discretionary) permissions, and so forth. Nothing is completely secure, but it is not as simple as, "Well they're on the server now, all is lost!"
- justincormack 14y agoIf you can log in via ssh (eg brute force) you normally get an unconfined login in normal selinux setups. But 20,000 hosts is not an ssh exploit, that would get more. Ah I see here http://malwaremustdie.blogspot.co.uk/2013/03/the-evil-came-back-darkleechs-apache.html http://malwaremustdie.blogspot.co.uk/2013/03/the-evil-came-b... that it only works in non selinux systems...