--1QGDfz3Tkbtkncdd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 08, 2005 at 06:20:22PM +0300, Elad Efrat wrote:
> Thor Lancelot Simon wrote:
> >I think this is the wrong way to go.  I think that it would be much bett=
er
> >to associate systrace policies with executables using verified exec, as
> >we discussed some months ago -- and this avoids adding another bag on the
> >side of the system that largely duplicates what systrace can do.
>=20
> I believe the idea of having capabilities was to enable a ``fast path''
> for more than just allow/deny. I certainly don't like the idea of having
> two systems that do the same, but I'm now in the process of thinking how
> would be the best way (IMHO) to implement it.

If you consider the systrace policy to be a set of capabilities (ie,
permitted syscalls), and the veriexec fingerprint of that to be the
'authorisation certificate' for that policy (ie, root declaring this
policy is valid and allowed to make '.. permit as root' statements), I
think you're a long way towards the goal.

> It's important to remember that for systrace to be useful, you have to
> run the program through it.=20

Agreed, but if that's the way to gain the capability you need...

> At the moment we have no way to enforce that yet.=20

No, and that's an important aspect to round out the system, to ensure
that (properly certified) systrace policies are the only way to gain
the relevant capabilities.  Consider a securelevel (or similar) above
which no syscalls happen as root without systrace assistance.

> We also might want to supply default policies for some programs
> and/or daemons...

Certainly.

The area I see this model falling most short in at the moment isn't so
much in the area of capabilities (expressed as above), or in the
expressive power of those capabilities to describe a program's rights;
it's in the area of credentials and applying capabilities to users
like we can to programs.  (Yes, we can test real uid in every
program's systrace policy, but that's harder to manage than I'd like.)

Once we can pass/delegate credentials and capabilites safely between
processes (across the network, even?) we're starting to round out the
system and achieve something really useful.  I suspect these can be
represented as signed fragments of almost-systrace policy, but haven't
thought much about it beyond there.

--
Dan.
--1QGDfz3Tkbtkncdd
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (NetBSD)

iD8DBQFC9/jeEAVxvV4N66cRAhrqAKCaTybULBUTlUpu68V8NUojBoeN0gCbB7oy
N034vABpE0efifb1HpEzFHk=
=UX4z
-----END PGP SIGNATURE-----

--1QGDfz3Tkbtkncdd--