Re: 2001_05_09 patch against 2.4.4

From: Chris Evans (chrisat_private)
Date: Mon May 14 2001 - 12:55:45 PDT

  • Next message: Chris Evans: "Re: 2001_05_09 patch against 2.4.4"

    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.
    We're embedded firmly in practical security now, and the principle that I
    like to apply is to minimize the amount of privileged code paths available
    to attackers. Applying this principle can give very strong security. I'll
    use my vsftpd as an example. The vast majority of the code is carefully
    run as a non-root user in a chroot() environment. The chroot() is
    particularly powerful, because you can choose a filesystem root which
    doesn't contain any suid executables. This provides great robustness; a
    maliciously gained shell now has a much much reduced chance of leading to
    serious damage.
    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.
    It would be lovely to see the ability to adopt some form of syscall ACL -
    default deny! Many apps, once up and running, need the use of a very small
    syscall set. If applied properly, bugs in daemons could tend towards being
    useless to attackers - no DoS via excessive fork(), brk(), mmap(), etc. No
    increasing of privilege via exec(), no network abuses with connect(). You
    can see, the possibilities are interesting.
    Discussion invited.
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Mon May 14 2001 - 16:56:42 PDT