Re: Slides

On Mon, August 5, 2013 00:30, Jonathan S. Shapiro wrote:
> So some general comments:
>

Hi Jonathan, tnx for the feedback.

> 1. Lots of things referenced in these slides that the audience probably
> doesn't know about.

Ack, although the OHM crowd does have a substantially higher understanding
of basic information security principles than my usual (most often
forensics/law-enforcement) crowd.

> 2. Some of the claims are, in my opinion, stated in too strident a form to
> be effective. Better to under-promise and over-deliver.

Could you please elaborate?

> 3. Have you looked at how this might inter-relate to the authentication
> and
> key management mechanism in Plan 9 (factotum)?

I had not before, looks like something I should read up on soon. I'll get
back to you on that one once I've seriously looked into it.

> 4. Probably an FAQ, but how does MinorFS deal with the fact that certain
> programs run multiple instances with distinct capabilities?

In the existing MinorFs there exists just one granularity, that of the
pseudo-persistent-process. These pseudo-persistent-processes work with
so called 'slots' that are handed out in order. Next to that, the command
line can be made part of the relevant process properties, so a
pseudo-persistent-process needs to be re-started with exactly the same
command-line.


http://www.linuxjournal.com/magazine/minorfs?page=0,3


Basically this should take care of the scenario you mention, but only as
long as the pseudo persistent process as a whole is a usable concept.

In MinorFs, if a process is started from a startup script, or if its
started from a normal terminal, or if its started from an ssh session,
than those 3  can not be the same pseudo-persistent-process.

I'm still examining what sets of process properties the first release of
MinorFS2 should support, but the following are the absolute minimum I know
I will need to support from the start:

1) The old pseudo-persistent-process (complete with slots)
2) The binaries/uid combination, that is the same program running
   with the same libraries under the same uid.
3) The 'toolset'/uid combination. Some tools come in sets and use the same
   dotProgram type directory.
4) uid only.


And some candidates that for now I'm projecting for a 2.1 version:

5) A semi free-floating pseudo persistent process, that is like the
   pseudo-persistent-process but agnostic for any parent chain properties
   except for the uid's in the process parent chain. That means that
   root->jonathan:/bin/foo can not be the same pseudo persistent process
   that root->wwwrun->root->jonathan:/bin/foo is.
6) A free-floating pseudo persistent process, that is like the
   pseudo-persistent-process but agnostic for any parent chain properties.
7) binary only (regardless of uid)
8) toolset only (regardless of uid).

I hope the above makes sense,

Rob


> _______________________________________________
> cap-talk mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/cap-talk
>