Crispin Cowan <crispinat_private>: > "Anil B. Somayaji" wrote: [snip] > > If you want to mess with system calls, you should mess > > with them in kernel-space - anywhere else is either too expensive, > > insecure, or both. > > I don't actually see a performance issue with hooking at the syscall interface. > And in fact, you can already hook syscalls by reloading the system call table. > The catch is that you don't have much context when you hook at the system call > level, i.e. you know the arguments to (say) open, but you don't know anything > about the inode number that it will resolve to after it gets through namei. > > This is exactly the quandary that SubDomain and LOMAC faced. SubDomain "solved" > it by punting and going with a kernel patch. LOMAC solved it by re-implementing > parts of the kernel in their module. The security LKM is supposed to relieve > security modules from having to use either of these sub-optimal solutions. It would seem (relative ignorance at the moment) that the permissions should be checked in namei, while namei is performing it's lookup. Each permissions check should refer to the security module/manager/whatever for grant/fail on the activity. Once namei gets done (successfully), the do_open/do_exec must confirm the final action. The difference between these two locations is that namei may cancel the final action with an error; the final action will have nothing to do with file lookup. It will either open the file, or exec the file. If exec; then the inheritable capabilities/security context... must be determined by the security module. If open, then the file permissions only are checked. > > > I actually do believe that sometimes you do care that a program is > > writing to /dev/null - especially if that program normally writes to a > > log file! But really, what it comes down to is that many people have > > proposed and tested effective security mechanisms that work at the > > system-call level. > > True, but couldn't that be detected through a hook deep down in open? What just > cannot be mediated with hooks in open? Quick answer: processes share file > descriptors, so you also have to mediate read and write. have to mediate mmap too. > But what else? Depending on the use of clone: sockets (via file discriptors) shared memory semaphores signal events (inherited configuration) resource limits (inherited values, until beancounter accounting) Whether all of these require mediation on fork could be up to the security module (or a resource accounting module) is policy dependant. In one case, the ability to create a network connection must be mediated - If the policy requires that "users cannot establish communication with unknown remote hosts" then the socket and connect system calls (maybe only the connect) have to be mediated by something. This gets difficult when some users are not allowed, some are. Those that are, are allowed to connect only to a certain class of hosts. Each user may have a different list of allowed hosts. Some of this can be/should be part of an IPSec implementation. Other functions, like socket/bind, may not be permitted at a low level where system call interception would be most efficent. A capability test by the security module would grant/deny use of the system call. The advantage would be that the overhead for deny would minimized instead of having to pass the decision up to something like IPSec (which may not be present), and still allow for a facility policy that prevents users from creating arbitrary servers/network connections. > > So, while I like the general idea of interposing on system calls, I > > see lots of problems with doing it in practice. I'm curious - what do > > other people actually want to do to system calls? How much info is > > needed? Maybe we can't have a really flexible API, but maybe we can > > have one that does 90% of the job for 10% of the effort and 1% of the > > slowdown. > > That's the goal. Part of the difficulty is in determining what is/should be part of the security context. Some things are obvious (security level, inode, ...) others are less obvious (uid, gid, gid list...). And where should capabilities be placed - MAC almost certainly, but ACL's have been known to carry capability lists, and those are usually evaluated under DAC. (a bit of blithering - sorry :-) ------------------------------------------------------------------------- Jesse I Pollard, II Email: pollardat_private Any opinions expressed are solely my own.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:15:24 PDT