On 2020-02-25 11:11, Hendrik Boom wrote:
> Which is the reason for a capability architecture. Is there anything
> resembling that in GNU/Linux userspace?

Kind of, not really.

There is something similar to role based access control, namely the unix
file permission model, which is a kind of DAC. Users and groups
(=roles), can have different permissions on files (reading, writing,
executing).
Then there are the security modules. These can extend that
functionality, which is usually used to add some kind of MAC.

For processes / syscalls, Linux has capabilities as a replacement for
things usually reserved for root, but these usually aren't very useful,
they are crude and can often be used to escalate to root anyway.
For syscalls, there is also seccomp, but it's hard to use and
architecture dependent, and it will break applications which use it
regularly.

Something which is currently missing is a way to manage permissions for
specific ioctls. Usually, its per device, and some ioctls need need read
or write permissions to the fd. Sometimes, that's suficent, sometimes
not.
There is kind of a horrible situation with /dev/dri/card* devices, if I
remember correctly, you need root for the ioctls to become drm master
and do modesetting, even if you have read and write permissions to the
file, which is why this is delegated to logind or a suid binary, I
think? One way to resolve this would be to splitt those card devices
into multiple ones, but I don't think that's going to happen. I don't
think configurable supplementary group based per ioctl permissions are
going to happen either. Except maybe as an LSM.

One interesting thing about files is that permissions are only checked
when those are opened. A file descriptor is like an access token. And
they can be sent over unix sockets, which can also be files. Those file
descriptors are unrevokable, though.

There is also a small problem with the DAC permission model. A process
has only one set of user, group, supplementary groups. This means,
either you can use them to restrict a program, or you can use them to
restrict a user, but you can't have restrictions based on a user and a
program. I was thinking a lot about this at some point, and wanted to
write an LSM for that at some point, but I never got to to it. I did
write down my thoughts, although retrospectively, I did make various
mistakes and misused some terminology there in there:
https://github.com/Daniel-Abrecht/Discretionary-Program-Access-Control/blob/proposal/Discretionary%20Program%20Access%20Control.md

It's possible that there are still some other access control mechanisms
I don't know of yet.