Re: 2001_05_09 patch against 2.4.4

chrisat_private

* Chris Evans (chrisat_private) wrote:
> 
> On Thu, 10 May 2001, Chris Wright wrote:
> 
> > >
> > > 2) I see, currently, that syscalls are not hooked in a generic manner.
> > > >From exceptionally brief scanning of the archives, this seems to be a
> > > debated point.
> > > Are there plans to hook syscalls? If not, I can make a very strong
> > > argument to do so. Let me know if you want to hear it.
> >
> > Some syscalls are hooked right now.  In general we have not hooked every
> > syscall.  I value your input here.
> 
> All right, here goes :-)
> 
> I'm going to propose an argument which detaills why some form of hooking
> or control on a per-syscall level is required. As a quick disclaimer, I'm
> not necessarily saying that LSM needs to provide this. I'm just arguing
> that _something_ should provide it.

Here I totally agree.  Projects like pH (Anil B. Somayaji and Stephanie
Forrest's work at UNM) strictly need syscall interpostion.  It is not yet
clear that this will be added to the LSM interface, as we have been more
concerned with the kernel objects themselves than the syscall interface
that exposes them (as I mentioned before I am in favor of pushing the
security interface as close to the kernel object as possible).

> However, like a suid executable, the syscall interface also crosses a
> privilege boundary. There are a lot of syscalls! In the absence of the
> ability to hammer on suid executable bugs, a competent attacker must
> surely turn to the Linux kernel syscall API as a source of boosting their
> privilege. This is an entirely feasible attack approach - look at the
> sysctl() and getsockopt() vulnerabilities I found recently. These _kernel_
> level bugs are deadly. Suddenly, your lovely MAC module to protect your
> very sensitive data is useless... and the current LSM hooks would probably
> not protect against these of other similar bugs.

I agree that these bugs are deadly, and may undermine your LSM module ;-(
But I'm not sure we need any explicit support for across the board syscall
interpostion in the LSM interface.  Because of the nature of the syscall
table, it is easy enough for an LSM to overwrite the syscall table with it's
own set of wrappers.  In this way it would be easy to get the default deny
policy you might be interested in from a module without adding the burden
of the ~220 syscalls to the already large (and likely to keep growning) LSM
interface.

-chris

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module