Re: dynamic /bin /sbin

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

    There are a couple of issues here that I would like to address.  One
    of the biggest goals on my list will be the ability to abstract a VFS
    into userland as part of the general workings of the system.. that is,
    not just as a root-only exercise.  I want to use such abstracted VFSs
    for all sorts of cool things such as isolating packages for the purpose
    of detecting and enforcing their library & configuration file
    dependanciese.

    This introduces some rather interesting problems that need to be solved.
    I am not all that worried about the kernel<->user interface, I've got 
    that pretty much worked out in my head.  The problems are all security
    related, because now access to the VFS itself needs to be properly
    secured.  We can't have suid-root programs going off accessing non-root
    VFSs without explicitly saying they want to, for example.  On the
    other hand, we *DO* want to be able to operate/simulate suidness within
    sub-environments as a better way to implement a jailed environment,
    and we need to be able to protect secure information on unsecure VFSs,
    through encryption, in a manner that does not count on the
    trustworthyness of the filesystem layer.

    For example, take a situation where a secure program wishes to access
    a secure space through an unesecure VFS or medium.  The only way to do
    this safely is not only for the data to be encrypted, but also for
    the secure program to emplace its own, trustworthy VFS layer on top
    of the VFS layer it is accessing which is able to verify and guarentee
    the consistency of the meta-data (directory structures and so on),
    and enforce constraints such access timeouts and such.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>

:Well, the problem I have specifically in mind is service discovery: one of
:the nice things (yes, there are some) about UNIX domain sockets is that
:they exist in a protected hierarchal namespace.  One of the problems that
:exists in OS X is that services are looked up in a non-hierarchal
:bootstrap namespace with few controls over use of the namespace.  If your
:"foo" service provider dies, another process using the same namespace can
:advertise the service.  One of the cool things about Mach is that you can
:provide new namespaces wrapping old namespaces--one of the less cool
:things about it is that you can't trust the namespace and that makes the
:life of an application writer more difficult.
:
:So, for example, you want to make sure that if you use a name to
:rendezvous with your directory service, you want to make sure you can
:ensure that name is properly protected from inappropriate use.  A
:hierarchal namespace with permissions of some sort is one way to do that,
:and might well make a good starting point if you start with a UNIX base.
:
:Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
:robert@xxxxxxxxxxxxxxxxx      Network Associates Laboratories