Now another syscall. I recently implemented capabilities, and decided to
use a version number that's different from the one Linux uses. I guess
that's exactly how I should have done it, but can you confirm me that
this is acceptable?
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?
Thank you,
Emmanuel
> 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
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