Allowed modules list

Posted Mar 19, 2004 1:40 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

A list of allowed modules won't help much if a user has root privileges.

It would if you implemented the rest of the proposal, which was to make the kernel not allow updating of this list by anyone. It was, of course, left vague how you might design something like that.

With any *nix once root is obtained the system is completely compromised.

That's very on-point. It's why the best reaction to this type of threat is to make it harder to "obtain root," by making "root" far less pervasive in a system.

Linux took steps toward this long ago by replacing the traditional Unix concept of superuser/not superuser with a set of fine grained capabilities. As has been pointed out, if you had every one except CAP_SYS_MODULE, you would not be able to install Adore. And if only processes that needed CAP_SYS_MODULE had CAP_SYS_MODULE, it would be next to impossible for the cracker to find one that he can trick into loading Adore.

It isn't customary on Linux systems to manipulate individual capabilities, but it should be.

For that matter, there's still a whole lot of code running with full capabilities that doesn't need any of them at all. I.e. it should "drop root."

One thing I don't know the status of: capabilities assigned to executables. Last I saw, if you need a privileged program, you have to make it setuid/owner 0 and then whoever executes it gets ALL capabilities. We need to do better than that.

Posted Mar 19, 2004 1:51 UTC (Fri) by AnswerGuy (guest, #1256) [Link]

It's not quite true that root-compromised systems *have* to be
inherently, persistenly compromised. It's CLOSE to true; but
some features in LIDS and SELinux could protect a well configured system
even from a rogue root process. These patches work by limiting root's
power and imposing additional authentication/authorization measures for
some operations.

JimD