Bruce Schneier has just written about the Storm Worm [1] which has apparently been quietly 0wning some Windows machines for most of this year (see the Wikipedia page for more information [2]).
I have just been asked whether SE Linux would stop such a worm from the Linux environment. SE Linux does prevent many possible methods of getting local root. If a user who does not have the root password (or is not going to enter it from a user session) has their account taken over by a hostile party then the attacker is not going to get local root (unless there is a kernel vulnerability). Without local root access the activities of the attacker can be seen by a user logged in on another account – processes will be seen by all user sessions if using the SE Linux targeted policy and files and processes can be seen by the sys-admin.
If while a user account is 0wned the user runs “su –” (or an equivalent command) then in theory at least the attacker can sniff this and gain local root access (whether enough users do this to make attackers feel that it’s worth their effort to write the code in question is something I couldn’t even guess about). If the user is clueless then the attacker could immediately display a dialog with some message that sound urgent and demand the root password – some users would give it. If the user is even moderately smart the attacker could fake the GUI dialogues for installing updated packages (which have been in Red Hat distributions for ages and have appeared in Debian more recently) and tell the user that they need to enter the root password to install an important security update (oh the irony).
In conclusion I think that if a user is ill-educated enough to want to run a program that was sent to them in email by a random person then I expect that the program would have a good chance of coercing them into giving it local root access if the user in question had the capability of doing so.
Even if a Linux trojan did not have local root access then it could still do a lot of damage. Any server operations that don’t require ports <1024 (which means most things other than running a web, DNS, or mail server) can still be performed and client access will always work (including sending email). The trojan would have access to all of the user’s data (which for a corporate desktop machine usually means a huge network share of secret documents).
If a trojan only attempts to perform actions that SE Linux permits (running programs from the user’s home directory, accessing servers for DNS, HTTP, IRC, SMTP, and other protocols – a reasonable set of options for a trojan) then the default configuration of SE Linux (targeted policy) won’t stop it or even log anything. This is not a problem with SE Linux, just a direct result of the fact that in every situation a trojan can perform all operations that the user can perform – and if the trojan only wants to receive commands via web and IRC servers and send spam via the user’s regular mail server then it will be a small sub-set of the permitted operations for the user!
If however the trojan tries more aggressive methods then SE Linux will log some AVC messages about access being denied. If the sys-admin has good procedures for analysing log files they will notice such things, understand what they mean, and be able to contain the damage. Also there have been at least two cases where SE Linux prevented local root exploits.
Finally, in answer to the original question: SE Linux will stop some of the more aggressive methods that trojans might use. But there are still plenty of things that a trojan could do to cause harm which won’t be stopped or audited by SE Linux policy. When Linux gets more market share among users with a small amount of skill and no competent person to do sys-admin work for them we will see some Linux trojans and more Linux worms. It will be interesting to see what methods the trojan authors decide to use.
Indeed, this is one important aspect I’ve been thinking about lately. It’s a known thing that Ubuntu machines come with sudo preconfigured to any regular user. This is, certainly, a security problem. The “regular user” should have much more limited access than it has today, I mean, even for non-root operations. As you said, working just like the Storm Worm does, it wouldn’t even require root priviledges.
One thing some guys I know do is to remove the ability to run things from the home mount, as for the tmp mount (anything but /usr really needs exec permission). This reduces the chances for a trojan to be executed, requiring the use of much more complex engines to be able to run the malicious code (like using /usr/bin/perl to dl_load some malware in $HOME and then call it, or just setting LD_LIBRARY_PATH to something inside $HOME that would have the malicious code). This are also things that would be undetectable by SE Linux. But at least, that way we would stop the simple “click here to get infected”, requiring a software vulnerability that would allow that arbitrary code execution (at least for installing the trojan).
This is something the linux installations need to care more about (and that’s why I love Debian not giving sudo by default), and perhaps starting to, by default, creating a separated home and tmp mount without execution permission at all…
What do you think?
Daniel: It’s obvious that having noexec,nodev for mounting /home and /tmp will have some security benefits, but they also have some usability issues – some of which are subtle and can waste large amounts of debugging time. That idea seems to not work well.
Also as you note interpreters (of which Perl is one of many on a typical Unix system) can perform all manner of interesting operations.
One possibility is to use the pam_namespace module (which wasn’t yet in Debian last time I checked) to give some users a non-executable /tmp but not others.
These are really difficult problems. Until we get good controls on the X protocol in use whatever we do will probably be inadequate in many ways.
Another option would be to put KVM on the desktop machine, and give the host a minimal userspace with no user accounts and all-or-nothing upgrades (checksum its root partition at boot.) Then the host can watch the guest’s filesystem and network traffic in and out, and zap it if it’s naughty.
[…] Yid With Lid wrote an interesting post today onHere’s a quick excerpt […]
[…] jeff159 wrote an interesting post today onHere’s a quick excerptBruce Schneier has just written about the Storm Worm (1) which has apparently been quietly 0wning some Windows machines for most of this year (see the Wikipedia page for more information (2)). I have just been asked whether SE Linux would stop such a worm from the Linux environment. SE Linux does prevent … […]
> SE Linux does prevent many possible methods of getting local root.
Just wondering, which methods would this be?
http://etbe.coker.com.au/2007/10/10/how-se-linux-prevents-local-root-exploits/
Olaf: The above post (which goes live tomorrow) has an answer to your question.
[…] Comments Anonymous on A Long Laptop Lifetimerob on A Long Laptop Lifetimeetbe on Can SE Linux Stop a Linux StormFelipe Sateler on Ideas for a Home UniversityOlaf van der Spek on Can SE Linux Stop a Linux […]