Re: disable-cap-mlock

William Lee Irwin III
2004-04-01T17:44:33Z

On Thu, Apr 01, 2004 at 12:37:51PM -0500, Stephen Smalley wrote:
> See dummy_capable for the root logic, i.e.:
> if (cap_is_fs_cap (cap) ? task->fsuid == 0 : task->euid == 0)
> return 0;
> Note that you shouldn't assume that task == current. The intent is to
> support capability checks against other processes as well, e.g. the old
> OOM killer code performed such checks as part of deciding which process
> to kill.

That's a bogon; thanks for checking.

On Thu, Apr 01, 2004 at 12:37:51PM -0500, Stephen Smalley wrote:
> Why fall through as opposed to just returning -EPERM?

It's a made-up thing, so the semantics are totally contrived. I had
in mind a "root bypasses all capability checks" thing. Maybe it should
die.

On Thu, Apr 01, 2004 at 12:37:51PM -0500, Stephen Smalley wrote:
> What prevents any uid 0 process from changing these sysctl settings
> (aside from SELinux, if you happen to use it and configure the policy
> accordingly)?

I'm aware it does some very unintelligent things to the security model,
e.g. anyone with fs-level access to these things can basically escalate
their capabilities to "everything". Maybe some kind of big fat warning
is in order.

-- wli

Index: mm4-2.6.5-rc3/security/sysctl_capable.c
===================================================================
--- mm4-2.6.5-rc3.orig/security/sysctl_capable.c 2004-04-01 09:07:36.000000000 -0800
+++ mm4-2.6.5-rc3/security/sysctl_capable.c 2004-04-01 09:41:41.000000000 -0800
@@ -145,7 +145,7 @@
return -EINVAL;
switch (capability_sysctl_state[cap]) {
case CAPABILITY_SYSCTL_ROOT:
- if (current->uid == 0)
+ if (task->uid == 0)
return 0;
/* fall through */