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

On Tue, Aug 09, 2005 at 06:41:37AM +0300, Elad Efrat wrote:
> >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.
>=20
> It will probably be implemented as per-process bitmaps of capabilities.

I think we're talking about different concepts of capabilities; see
hand-waving below.

> >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.)
>=20
> Could be you're confusing between process capabilities and user
> capabilities?

Perhaps; more specifically I was being deliberately vague about
separating them, because I'm not sure they need to or should be:

  - consider an abstract capability as "the ability to perform an
    action", and consider that represented as a suitably signed
    fragment of systrace-like rules describing the action and the
    conditions that must apply.  Let's avoid the terminology confusion
    by making up a new name for this, let's call it an "authorisation
    token".

  - consider that we might want these things to apply to both/either
    of a user or an executable

  - consider, as an additional aside, that we might want to attach
    such policy fragments to files as well, ACL-style.

Given that, it seems to make sense to me that they all be of a
consistent format; what do we gain by having user and process
capabilities be separate mechanisms/concepts?  In this model, the
thing that makes them a 'user' or 'process' capability is more in how
they're written.

We'll need some rules about how to combine the set of tokens each
brings with it into a cohesive policy.  All the fragments can write
tests with respect to any aspect of the context (uid, file name,
process name, etc) - but they're attached to the place that makes the
most sense to manage them. =20

So a file can carry a policy along the lines of "I can only be
accessed by this program", rather than trying to figure out how to get
the negative version of that into every other program's policy, for
example.  That's a weak example that could be simulated with ".. as
user", setuid-style; consider instead "a program with this file open
can't make network connections" or something.

Maybe that's a clearer restatement of about where I think the
discussion got to last time, with some extensions to illustrate why I
think it could be very powerful.  What I liked last time was the
"detached signature" aspect of using veriexec to validate the policies
as well as the binaries, wherever they came from.

What I'd like to see added to this model is a stronger form of
credentials to go along with the capabilities; proving the identity
(user or group membership) that the policy tests, or some more
detailed credential espression. Kerberos-like tokens that can be
delegated to various subsystems for network filesystem access on the
user's behalf, w2k domain style, or for per-process, per-user IPSEC
SAs, for example.

The less such a framework relies on identities and credentials that
are internal to a trusted local kernel, and the more that are stored
by (or on behalf of) a process in a secure unforgeable form, the more
this model will be applicable in wider environments.  We've covered
that partially, in the concept of using signed veriexec hashes to seed
the trust model/capability policy into the kernel, but the loop hasn't
yet been closed.

As an example implementation of such a concept, I once again point to
Java's JAAS.  There, you can assign rights to a code base, or to the
identity (Principal) who owns the thread executing it, or both.

--
Dan.


--6T2vOV0TokPza8xG
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFC+EBZEAVxvV4N66cRArXvAJ4kYCbDv1pQFCphR3eqSjQeHLdsFACeP5MB
B/KC5UjZ7IKOFCXYuyJfzzk=
=heIO
-----END PGP SIGNATURE-----

--6T2vOV0TokPza8xG--