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

> [sorry if this is a resend -- i don't think it worked the first
> time.]
> Olaf Dietsche wrote:
>> Andy Lutomirski <> writes:
>>>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
>> fi
>> exec /sbin/init.bin "$@"
>> ^D
>> # chmod 755 /sbin/init
>> # reboot
> Wow -- I missed that. Does anyone actually do this? And is there a
> reason why it should work like this?

Because in kernel/sysctl.c:
int proc_dointvec_bset(ctl_table *table, int write, struct file *filp,
void __user *buffer, size_t *lenp)
allows init only to set cap_bset.
You can write a module to set cap_bset, of course, or patch the kernel
to define CAP_INIT_EFF_SET to ~0.

>>>cap_bprm_set_security does:
>>>fP = fI = (new_uid == 0 || new_euid == 0)
>>>fE = (new_euid == 0)
>> Only if (!issecure (SECURE_NOROOT))
>> [...]
> I don't see any way to change securebits.

I thought there has been a /proc way, to set securebits, but maybe I
confused this with cap_bset. Anyway, here's the easy way out:

diff -urN a/include/linux/securebits.h b/include/linux/securebits.h
--- a/include/linux/securebits.h Sat Oct 5 18:42:33 2002
+++ b/include/linux/securebits.h Sun May 23 22:38:02 2004
@@ -1,7 +1,7 @@

-#define SECUREBITS_DEFAULT 0x00000000

extern unsigned securebits;

>> 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
>> so.
> I find caps to be broken, and I don't use SELinux. I want to be able
> to run programs as non-root with limited caps, which I currently can't
> do without modifying each program to start as root, then drop caps,
> then set KEEPCAPS, then drop root. And even with that change, these
> programs can't usefully exec themselves, which could be useful.

This is, where filesystem capabilities come into play. You implemented
them yourself. Execing is still a problem, though. However, if you
activate SECURE_NO_SETUID_FIXUP this issue is gone, too.

> And no, I don't think this patch is necessary, or that it should be
> applied or used by itself. I think it makes a good starting point to
> fix caps
> (which a lot of people seem to think are broken).

Well, I know, that I don't have a strong following. :-)

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.024 / U:1.776 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site