3 ms·
The problem with non integrated solutions (integrated as in in the application) is that people need different access restrictions depending on their specific us
by nwmcsween 15y ago
The 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)