3 ms·
This is what AppArmor and SELinux are used for. AppArmor has the ability to apply a profile whenever a particular binary is run, and so you can confine the proc
by cyphar 7y ago
This is what AppArmor and SELinux are used for. AppArmor has the ability to apply a profile whenever a particular binary is run, and so you can confine the process. SELinux has labels and all that jazz so you could probably configure it in a similar manner (though I think it doesn't support restricting all callers of a binary).
To a lesser degree, seccomp is similar but you don't have an easy way of applying a profile to a binary (instead the binary would need to self-apply the profile or you'd need to come up with a separate way of running programs so that a profile would be auto-applied).
The problem is that users want to be able to edit any file on the filesystem with their text editor -- if you don't allow vim to edit files in /etc/ then admins won't be able to do their job (though, please use "sudo -e" instead of "sudo vi").
- tremon 7y agothough I think [selinux] doesn't support restricting all callers of a binary It can, in two ways: the current context (say, user_dev_t) needs execute permissions on the declared type of the executable (say, git_exec_t), and additionally, you can declare a type transition to be performed per calling context. To keep with the git example (I admit it's a bit contrived), you could label your .git directory as git_repo_t and deny access for both user_t (normal user context) and user_dev_t (user dev context). Then, you can define a type transition as above (user_dev_t -> git_exec_t => git_t), and allow only the context git_t access to git_repo_t files. With this setup in place: - git, as called from within user_dev_t works as normally - git, as called from user_t, has no defined type transition so will try to access git_repo_t under the user_t context, which will fail.
- bboozzoo 7y agoI don't think SELinux would help much here, since users usually run as unconfined_t. I'd guess typical users also run `sudo <whatever>` without bothering to switch role/type.