Keeping track of called syscalls in real-time

[valdis.kletnieks at vt.edu]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20170628/f52f4e53/attachment.bin