Re: improving the Seatbelt system
Re: improving the Seatbelt system
- Subject: Re: improving the Seatbelt system
- From: Terry Lambert <email@hidden>
- Date: Mon, 28 Jan 2008 23:43:10 -0800
On Jan 28, 2008, at 5:03 AM, Michael Roitzsch wrote:
Hi,
The main area I'm interested in is dealing with user intent - e.g.
it would be really nice if there was a simple way for an
application to say that it will only use the standard paths (e.g.
~/Library/{Application Support,Preferences,Cache}/
com.example.app.*) and anything which the user has selected in a
standard open/save dialog, drag-and-drop, etc. which appears to be
currently impossible short of creating a separate process and
using IPC.
Indeed. Currently there are architectural restrictions that make
this sort of thing tricky. That's one of the reasons that Seatbelt
is not yet considered a public API.
Please /do/ file your enhancements requests; I don't think the
Seatbelt folks are on this list, but I can guarantee that they will
see any formal enhancement requests that you file.
Thanks for the note. I will file an enhancement request then. I
think a solution along the lines of model-carrying code could be a
quite pragmatic solution to deal with user intent, as it should be
trivial to validate a policy like the one suggested by Chris (only
allow apps to write to ~/Library/Application Support/com.example.app
and so on) against a syscall model of an application.
Practically, internally Seatbelt uses the MAC (Mandatory Access
Controls) framework (this should be obvious from DTracing seatbelted
operations, and looking at the published xnu source code).
MAC is the API Quinn references that's not published for third parties
to use, since it's not final, and we cropped out some of the more
expensive parts, at the same time adding in some control points where
we though it was lacking. If you build your own kernel, you can
choose to export the additional cropped-out APIs for your KEXTs, with
the understanding that we reserve the right to change any of them out
from under you in any release, and probably will.
MAC is all about actor, object, and action, and then controlling
whether or not its allowed. It's not about policies.
For example, the default policy module from SEDarwin is the NSA's
FLASK/TE model (but we don't include it). It can also support the MLS
(Multi Level Security) policy, and the Biba integrity policy, as well
as others. Seatbelt is a policy module; you could in theory
experiment with your own policy that implements your ideas (within the
constraints of the MAC chokepoints we implemented).
See the following for more information on MAC:
<http://www.trustedbsd.org/mac.html>
<http://www.sedarwin.org/>
<http://www.trustedbsd.org/>
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden