On Wed, 28 Jun 2017 20:16:33 -0300, Ben Mezger said: (By the way - fopen() is a glibc construct, not a syscall) > I understand seccomp and LSM allows __some__ type of syscall > interposition (where afaik seccomp blocks mostly all of them), but what > I am willing to do here is not *reinvent* the wheel, I am willing to > make things a bit more configurable, where a user has access to an API > where he could write custom procedures to run on the interception side, > without having to dig through the source. AppArmor, SMACK, SELinux, and Tomoyo all allow writing of user-readable policies in userspace and then applying the policy (through some combination of labelling and/or loading policy into the kernel at boot), without having to "dig through the source". In fact, it's probably impossible to write a non-trivial and yet actually usable LSM that doesn't work this way. So it sounds like you probably *are* re-inventing some wheels here. If you have a *very* recent kernel, you can probably get yourself into all sorts of trouble by creating an LSM that allows attachment of arbitrary BPF programs to the various hooks listed in include/linux/lsm_hooks.h. However, there's no really good way to allow unrestricted "custom procedures to run on intercept" that doesn't involve having a reasonably good idea of how the rest of the source works. You *really* want to restrict it to interpreting a policy language of some sort - at which point BPF is probably overkill. (For bonus points - spend at least 30-45 minutes thinking deeply about all the ways an attacker can use the ability to use "custom procedures on intercept" to attack the system. In particular, examine ways an attacker who gets root and/or "authority to load policy" can leverage it to load in a kernel-resident rootkit. See http://phrack.org/issues/58/7.html#article on SucKIT for a worked example of loading code into a kernel that doesn't even support modules.) Note also that you're going to have a *lot* of issues trying to do path-based security - there's all sorts of ugly things that can be done with deep nested paths, symlinks, remote NFS servers, and race conditions. And things like openat() and namespaces only add to the fun... And I'm convinced that even after some 4 decades, there's *still* code and systems configurations out there that allows naughty uses of multiple hard links to a file.
Attachment:
pgp7NDuWNqtE1.pgp
Description: PGP signature
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
