3 ms·
As many discuss the cap sys admin for processes, I'd like to point out that, some framework exists to alleviate the issue. It's not perfect but it exists. For
by zobzu 15y ago
As many discuss the cap sys admin for processes, I'd like to point out that, some framework exists to alleviate the issue.
It's not perfect but it exists.
For example RSBAC (www.rsbac.org) has a CAP module and which can forbid capabilities per process.
This won't save you when the kernel request it, but it doesnt when an app require it while it doesn't need it, which is what the article is about
- nwmcsween 15y agoThe problem with non integrated solutions (integrated as in in the application) is that people need different access restrictions depending on their specific use case.. This had led to what you see now in Linux with apparmor, grsec, selinux, smack, tomoyo, rsbac all with different incompatible outside solutions that don't really solve the problem or introduce a huge amount of technical overhead that only the developer of said application would have knowledge about. In short their useless due to time and effort needed.
- zobzu 15y agoNo, actually, RSBAC does this via policy. That is, the developer does not need to bother. The developer does what the developer does. The policy enforces it, regardless of the code. If in certain conditions, as a user, you disagree with the user of CAP_SYS_ADMIN, RSBAC denies it (context-based too, via other modules!) You can for example wrap that in a role-based policy, tied per binary, or simply by wrapping it in a RSBAC jail. (rsbac_jail -options /path/to/said/program) I don't think the other ones do that, as it's quite specific. They just plain deny. That's mostly because RSBAC has it's own framework (as does GrSecurity, but GrSecurity does not go as deep in that regard)