request: capabilities that allow users to drop privileges further

request: capabilities that allow users to drop privileges further

[Felix von Leitner]

I would like to be able to drop capabilities that every normal user has,
so that network servers can limit the impact of possible future security
problems further.  For example, I want my non-cgi web server to be able
to drop the capabilities to

  * fork
  * execve
  * ptrace
  * load kernel modules
  * mknod
  * write to the file system

and I would like to modify my smtpd to not be able to

  * fork
  * execve
  * ptrace
  * load kernel modules
  * mknod

I can kludge around some of these, for example I can disable fork with
resource limits, and I can limit writing to the file system with chroot
and proper permissions in the file systems, but I'm not aware of a way
to disable ptrace for example, or pthread_create.

I know that there are patches to provide an extended "jail" chroot
support, but being able to drop capabilities like this would be a more
general solution.

Felix

Re: request: capabilities that allow users to drop privileges further

[Richard B. Johnson]

On Mon, 15 Dec 2003, Felix von Leitner wrote:

> I would like to be able to drop capabilities that every normal user has,
> so that network servers can limit the impact of possible future security
> problems further.  For example, I want my non-cgi web server to be able
> to drop the capabilities to
>
>   * fork
>   * execve
>   * ptrace
>   * load kernel modules
>   * mknod
>   * write to the file system
>
> and I would like to modify my smtpd to not be able to
>
>   * fork
>   * execve
>   * ptrace
>   * load kernel modules
>   * mknod
>
> I can kludge around some of these, for example I can disable fork with
> resource limits, and I can limit writing to the file system with chroot
> and proper permissions in the file systems, but I'm not aware of a way
> to disable ptrace for example, or pthread_create.
>
> I know that there are patches to provide an extended "jail" chroot
> support, but being able to drop capabilities like this would be a more
> general solution.
>
> Felix

So you expect kernel support?  Normally, real people write or
modify applications to provide for specific exceptions to
the standards. They don't expect an operating system to
modify itself to unique situations. That's not what
operating systems have generally done in the past.

The 'C' runtime library interfaces to the kernel. You
can use the ld.so.preload capabilities to substitute
private functions for fork(), etc. This has the additional
benefit of allowing crappy, poorly-written, executables
that may have buffer overflows to be executed with
increased confidence. Of course, some root-shell programs
bypass the 'C' runtime libraries.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: request: capabilities that allow users to drop privileges further

[Christian Borntraeger]

Felix von Leitner wrote:
> I would like to be able to drop capabilities that every normal user has,
> so that network servers can limit the impact of possible future security
> problems further.  For example, I want my non-cgi web server to be able
> to drop the capabilities to
>
>   * fork
>   * execve
>   * ptrace
>   * load kernel modules
>   * mknod
>   * write to the file system

You can have a look at 
http://lsm.immunix.org/ and
http://lsm.immunix.org/lsm_modules.html
if there is something that fits your need. 
If not,  feel free to  write a security module, that is able to do just what 
you want. ;-)

cheers 

Christian

Re: request: capabilities that allow users to drop privileges further

[Chris Wright]

* Felix von Leitner (felix-kernel@fefe.de) wrote:
> I would like to be able to drop capabilities that every normal user has,
> so that network servers can limit the impact of possible future security
> problems further.  For example, I want my non-cgi web server to be able
> to drop the capabilities to

Using existing capabilities system you can limit many of these.  Just
dropping privs from uid = 0 to anything else is a good start.

>   * fork

rlimit

>   * execve

mount fs noexec

>   * ptrace

drop CAP_SYS_PTRACE

>   * load kernel modules

drop CAP_SYS_MODULE

>   * mknod

drop CAP_MKNOD

>   * write to the file system

mount fs r/o.

In general, most of what you ask for is already there.  Otherwise use
some MAC policy that gives you the control you want (check out SELinux
for example).

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: request: capabilities that allow users to drop privileges further

[Christian Borntraeger]

Richard B. Johnson wrote:
> On Mon, 15 Dec 2003, Felix von Leitner wrote:
> > I would like to be able to drop capabilities that every normal user
[...]
> > security problems further.  For example, I want my non-cgi web server
[...]
> >   * fork
> >   * execve
> >   * ptrace
[...]
> So you expect kernel support?  Normally, real people write or
> modify applications to provide for specific exceptions to
> the standards. They don't expect an operating system to
> modify itself to unique situations. That's not what
> operating systems have generally done in the past.
[...]

I dont agree. Policy is userspace but enforcing the policy very often needs 
kernel support.

Having ACL in 2.6 is an example where operating system already adopted to 
special needs. Furthermore, the kernel is already able to drop special 
capabilites, like module loading.  Having a generalised capabilites model 
is a good idea and there are already some more or less usable security 
modules.

cheers

Christian

Re: request: capabilities that allow users to drop privileges further

[James Morris]

On Mon, 15 Dec 2003, Felix von Leitner wrote:

> I would like to be able to drop capabilities that every normal user has,
> so that network servers can limit the impact of possible future security
> problems further.  For example, I want my non-cgi web server to be able
> to drop the capabilities to
> 
>   * fork
>   * execve
>   * ptrace
>   * load kernel modules
>   * mknod
>   * write to the file system
> 
> and I would like to modify my smtpd to not be able to
> 
>   * fork
>   * execve
>   * ptrace
>   * load kernel modules
>   * mknod

You can specify policy under SELinux to acheive this (without modifying 
any applications).


- James
-- 
James Morris
<jmorris@redhat.com>

Re: request: capabilities that allow users to drop privileges further

[Martin Waitz]

[-- Attachment #1: Type: text/plain, Size: 651 bytes --]

hi :)

On Mon, Dec 15, 2003 at 05:10:00PM -0500, Richard B. Johnson wrote:
> Of course, some root-shell programs bypass the 'C' runtime libraries.
of course, they have to as shellcode won't include a dynamic linker. ;)

so your approach does not help from a security point of view,
and felix only was concerned about security.

-- 
CU,		  / Friedrich-Alexander University Erlangen, Germany
Martin Waitz	//  Department of Computer Science 3       _________
______________/// - - - - - - - - - - - - - - - - - - - - ///
dies ist eine manuell generierte mail, sie beinhaltet    //
tippfehler und ist auch ohne grossbuchstaben gueltig.   /

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: request: capabilities that allow users to drop privileges further

[Martin Waitz]

[-- Attachment #1: Type: text/plain, Size: 587 bytes --]

hi :)

On Mon, Dec 15, 2003 at 02:48:09PM -0800, Chris Wright wrote:
> >   * ptrace
> 
> drop CAP_SYS_PTRACE
that will only help agains ptracing foreign processes.
you can still debug your own ones.

so this does not help agains buffer overflows&co in ptrace


-- 
CU,		  / Friedrich-Alexander University Erlangen, Germany
Martin Waitz	//  Department of Computer Science 3       _________
______________/// - - - - - - - - - - - - - - - - - - - - ///
dies ist eine manuell generierte mail, sie beinhaltet    //
tippfehler und ist auch ohne grossbuchstaben gueltig.   /

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: request: capabilities that allow users to drop privileges further

[Felix von Leitner]

Thus spake Chris Wright (chrisw@osdl.org):
> > I would like to be able to drop capabilities that every normal user has,
> > so that network servers can limit the impact of possible future security
> > problems further.  For example, I want my non-cgi web server to be able
> > to drop the capabilities to
> Using existing capabilities system you can limit many of these.

No.  The administrator can limit many of these.  I want the software to
be able to limit itself.

> Just dropping privs from uid = 0 to anything else is a good start.

If you give administrators tools to limit privileges, some well-educated
admins may do it, but the bulk will not.

If you give software authors the tools to drop privileges they don't
need, and you help everyone.

> >   * execve
> mount fs noexec

Not an option for a web server or smtpd.

> >   * ptrace
> drop CAP_SYS_PTRACE

That will still allow the process to ptrace other processes of the same
uid.

> >   * write to the file system
> mount fs r/o.

Again, not an option.

I hope I made myself more clear this time.

I would be happy with a well documented and fine grained capabilities
system, and maybe a new syscall:

  abstain(__NR_execve);

I would also like a way to say that I want to never access the network
except through sockets that are already open (and presumably passed to
me at process creation).  Dan Bernstein has a good rationale on what I
think is needed: http://cr.yp.to/unix/disablenetwork.html, however I
think if we do this, we might as well opt for more flexibility.

Imagine being able to call "gzip -dc" in a pipe and denying it write
access to the file system, network I/O and other harmful operations.
If programs can restrict themselves, we could write email client
software that uses external untrusted plugins without fear of buffer
overflows or catching yourself a root kit.

Felix

Re: request: capabilities that allow users to drop privileges further

[Chris Wright]

* Felix von Leitner (felix-kernel@fefe.de) wrote:
> Imagine being able to call "gzip -dc" in a pipe and denying it write
> access to the file system, network I/O and other harmful operations.
> If programs can restrict themselves, we could write email client
> software that uses external untrusted plugins without fear of buffer
> overflows or catching yourself a root kit.

Write some SELinux policies for the email and web server that do what
you'd like.  The LSM infrastructure allows you to control all these
things, and SELinux gives a configuration language to do this with.
Or you can write a simple module to do just what you'd like.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net