Blargh. I should take a bit more time to think before posting. What I meant was: class foo:
def __init__(self, n):
self.n = n
def __call__(self, i):
self.n += i
return self.n
The point is, once you have root, there are any number of ways to compromise the system and hide your exploits.
That's not necessarily true on recent Linux versions, or at least it isn't for the reasons that you listed. Aside from the fact that/dev/kmem and loadable modules can be disabled, even if those features are active, not all processes with UID 0 necessarily have access to them. For quite some time now, Linux has included support for POSIX Capabilities. The API is ugly as heck, and unfortunately there isn't any FS support (analogous to set{u,g}id flags) yet, but the basic functionality (dropping selected capabilities, changing UID without dropping capabilities) does work. Module (un)loading is CAP_SYS_MODULE. Ignoring file permissions is CAP_DAC_OVERRIDE. There's some other pretty critical stuff like CAP_MKNOD, but in principle it should be possible for a uid 0 process to have no special privileges whatsoever. Access to binfmt should not change this fact.
Of course, in practice there probably aren't very many vanilla linux systems that rely on this at the moment. If one does want to retain only some privileges, the sound practice is to not only drop the others but also change UID; for one thing, a lot of critical files (like/etc/shadow) are still owned by uid 0 by default.
Slashdot Mirror
Blargh. I should take a bit more time to think before posting. What I meant was:
class foo:
def __init__(self, n):
self.n = n
def __call__(self, i):
self.n += i
return self.n
Python:
class foo:
def __init__(self, n):
self.n = n
def __call__(self, i):
self.n =+ i
return i
That's too long/complicated for you?
The point is, once you have root, there are any number of ways to compromise the system and hide your exploits.
/dev/kmem and loadable modules can be disabled, even if those features are active, not all processes with UID 0 necessarily have access to them.
/etc/shadow) are still owned by uid 0 by default.
That's not necessarily true on recent Linux versions, or at least it isn't for the reasons that you listed. Aside from the fact that
For quite some time now, Linux has included support for POSIX Capabilities. The API is ugly as heck, and unfortunately there isn't any FS support (analogous to set{u,g}id flags) yet, but the basic functionality (dropping selected capabilities, changing UID without dropping capabilities) does work.
Module (un)loading is CAP_SYS_MODULE. Ignoring file permissions is CAP_DAC_OVERRIDE. There's some other pretty critical stuff like CAP_MKNOD, but in principle it should be possible for a uid 0 process to have no special privileges whatsoever.
Access to binfmt should not change this fact.
Of course, in practice there probably aren't very many vanilla linux systems that rely on this at the moment. If one does want to retain only some privileges, the sound practice is to not only drop the others but also change UID; for one thing, a lot of critical files (like
$ file
$ file
That would be ripping off StupidaScreen (described at the bottom of the page).