[lkml]   [2004]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] scaled-back caps, take 4
Andy Lutomirski <> writes:

> You don't like my patch because it rips out a bunch of code and it's
> not clear it won't break stuff.
> I don't like your patch because it takes a bunch of incomprehensible
> code that does almost nothing and tweaks it slightly to do something
> useful. (That's not to say it's does the wrong thing; I just don't
> think the code is clear.)
> So I decided to figure out what was going on with the original code.
> First, CAP_SETPCAP is never obtainable (by anything).
> Since cap_bset never has this bit set, nothing can inherit it
> from fP. capset_check prevents it from getting set in pI.

# mv /sbin/init /sbin/init.bin
# cat >/sbin/init
#! /bin/sh

if test $$ -eq 1; then
mount /proc
echo -1 >/proc/sys/kernel/cap-bound

exec /sbin/init.bin "$@"
# chmod 755 /sbin/init
# reboot

> Second, cap_bset is broken. For one thing, there's no way
> to remove the caps you want to restrict from already-running
> tasks. So I don't think it matters if we break/change it.

Maybe I don't understand this, but I think this is what sys_capset()
is for.

> cap_bprm_set_security does:
> fP = fI = (new_uid == 0 || new_euid == 0)
> fE = (new_euid == 0)

Only if (!issecure (SECURE_NOROOT))

> The whole result is just
> pP' = (uid == 0 || euid==0) & X
> pE' = (euid == 0) & X
> This patch implements this. It should be invisible to userspace
> (unless userspace (ab)uses cap_bset). It also adds a secureexec
> flag, which we both need.
> First, did I get this right? It seems to work :)

With this patch you effectively revert all capable() calls back to
suser() tests. If this is what you intended, your patch looks fine.

> Second, do you have any objection to both of us redoing our
> patches against this one? It should make them nicer-looking
> at least.

I didn't scrutinize capabilities as thoroughly as you did, but I still
don't see why your patch is necessary, besides the changes in
fs/exec.c and include/binfmts.h, maybe.

$ cp commoncap.c lutocap.c
modify it to your liking
# insmod lutocap

same goes for chriscap.c

Please, don't get me wrong. For me, it's just a matter of maintaining
a slightly bigger fscaps patch. But I don't think capabilities in
Linux are really broken, only because some proponents of SELinux claim

If you want a simpler - setuid like - capabilities model, throw out
the inheritable _and_ permitted set and use the effective set alone.

Regards, Olaf.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:03    [W:0.180 / U:0.388 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site