Kernel compatibility : capset(2)

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

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