linux-kernel - Re: [RFC][7/11][MANUX] Kernel compatibility : capset(2)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <534D5356.6080605@manux.info>
Date:	Tue, 15 Apr 2014 17:42:14 +0200
From:	Emmanuel Colbus <ecolbus@...ux.info>
To:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
CC:	linux-kernel@...r.kernel.org
Subject: Re: [RFC][7/11][MANUX] Kernel compatibility : capset(2)

Le 15/04/2014 17:10, One Thousand Gnomes a écrit :
>> Also, for your information, I decided to use 64-bit capabilities, in
>> order to give a possibility to reduce the rights of an unprivileged
>> software (for example, if a process lacks CAP_USR_CHMOD, it won't be
>> able to perform a chmod on an existing file). This means I'm not using
>> the same data structure as you; do you have any objection to it?
> 
> Save yourself the effort. The Linux old style capble() model is basically
> broken. It's vaguely useful if you combine it with SELinux to repair some
> of the awkward cases.
> 
> The world has moved on to MAC/DAC and is heading now for real
> "capability" based security which is nothing to do with having a bunch of
> bit flags.
> 
> Alan
> 

Oh, I know. In fact, this is just a bit of icing on the cake, as I
already use true capability-based security. But I considered it, and I
decided this shouldn't be harmful (save for the very small slowdown at
each syscall), and that there could be cases where this little added
security could be useful, so since I needed the syscall for Linux
compatibility anyways, I decided to add it.

(As an example, if you've two processes that run in the same chroot, but
only one of them that can have a valid reason to call execve(2),
removing CAP_USR_EXECVE to the second one ensures it can't perform an
exec on the binaries used by the first one. In my OS, this would
actually improve security, because most binaries are actually wrappers
used to jump across chroots, so a true execve(2) is quite different from
a manual ELF loading.)

Emmanuel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/