[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LRH.2.00.1011090936150.29639@tundra.namei.org>
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.
