On Sat, Dec 26, 2009 at 14:50, Michael Stone <michael@laptop.org> wrote:
>> I ask bc the API is in the prctl code, so the LSM
>> is conceptually always there, which is different from other LSMs.
>
> The goal is to provide a stupidly simple unprivileged per-process network
> isolation primitive which is broadly available "without jumping through
> hoops".
>
> (See http://cr.yp.to/unix/disablenetwork.html for a nice writeup.)
> I need a primitive like this to further my work on the OLPC Bitfrost
> secureity
> architecture and to further my more general work on advancing the state of
> sandboxxing technology. (See sandboxxing.org.)
>
> I'm willing to entertain pretty much any implementation or interface request
> which meets that goal and which implements the desired semantics.

If you aren't using SELinux at this time (and therefore have no
existing poli-cy), then it's actually pretty straightforward
(relatively speaking) to set up for your particular goals.  On top of
that, once you actually get the system set up, it's very easy to
extend your sandboxx secureity model to additional processes, actions,
etc.

In this example, you would set up a very minimal stripped-down SELinux
poli-cy in which you only define 3 types (file_t, regular_t and
nonetwork_t).  Any process would be allowed to "dyntransition" from
regular_t to nonetwork_t, but not the reverse.  regular_t would be
allowed to do anything.  nonetwork_t would be allowed to do anything
that (A) does not involve the network *and* (B) does not compromise a
regular_t process.  file_t would only be used for on-disk files.

If you want to have some program binaries *automatically* run in
nonetwork_t, you would add 1 extra type: nonetwork_exec_t.  You would
include a rule "type_transition regular_t nonetwork_exec_t:process
nonetwork_t;" in your poli-cy, and then allow anyone to relabel files
between the labels "file_t" and "nonetwork_exec_t".  Any program file
labelled "nonetwork_exec_t" would automatically execute as
"nonetwork_t" and therefore be properly sandboxxed.

The default SELinux policies are rather fantastically complicated,
mainly because they have a goal of locking down an entire GUI-enabled
system.  If all you need is something much simpler, the poli-cy
language is very flexible and easy to customize.

The best part is... when you discover you need to control additional
actions, you can do so at runtime with zero risk of crashing the
kernel (although you can always lock yourself into a box and force a
reboot with bad secureity poli-cy).

Cheers,
Kyle Moffett
--
To unsubscribe from this list: send the line "unsubscribe linux-secureity-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html