Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 9 Nov 2010 10:39:20 +1100 (EST)
From: James Morris <jmorris@...ei.org>
To: oss-security@...ts.openwall.com
cc: Daniel Walsh <dwalsh@...hat.com>
Subject: Re: filesystem capabilities

On Mon, 8 Nov 2010, Solar Designer wrote:

> Thanks for reading this far, and I'd appreciate any comments and/or
> corrections.

I think it'd be worth taking things a step further and reworking these 
privileged apps so that they are split into separate privileged and 
unprivileged sandboxed programs (let's call them launchers and workers).

The general idea is to have a minimal launcher, which does nothing except 
access a resource requiring privilege, then launch an unprivileged worker 
to utilize that resource.

Authority is bundled with with the resource via its file descriptor, and 
passed to the worker, which then requires no general privileges at all.

The worker task can then be tightly sandboxed with seccomp / SELinux / 
namespaces etc., communicating back to the launcher via the fd.

(This is an application of concepts from object-capabilities and privsep).

SELinux (and possibly TOMOYO) could also be used to help ensure correct 
invocation of resources and worker tasks.

In the case of ping, the launcher would open a raw socket, then launch a 
worker, passing in the raw socket's fd.  Anything not absolutely required 
in the launcher would be implemented in the worker (command line parsing, 
sending and receiving messages, generating user output etc.).  The worker 
would not need access to any resources except fds passed by the launcher, 
so it could for example be launched in a private namespace and in seccomp 
mode.  Thus, there is no 'ambient' authority to access the system, and the 
system-level attack surface is also reduced (e.g. prevent a buggy ioctl() 
being called on a passed-in fd).

Applied across the system, the aim would be to separate out all privileged 
function into minimal, audtiable programs, while also more fully applying 
the principle of least privilege to the worker programs.



- James
-- 
James Morris
<jmorris@...ei.org>

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.