[redhat-lspp] Re: [Fwd: Re: [Fwd: Polyinstantiated directories]]

[Janak Desai]

Alexander Viro wrote:

> Very brief notes on their draft:
> 
> 	In filtering approach: process attempting e.g. mkdir in
> the filtered directory will be able to see if anybody else has an
> object with given name, even though it could not see that object
> in getdents() results.
> 
> 	It's not just a risk of problems due to collisions; it's a
> potentially serious covert channel.  _And_ avenue for deliberate DoS.
> 

Understood.

> 
> 	Hidden intermediate directories pose another problem missed in
> analysis - removal of these guys and their behaviour upon rename()
> is going to have interesting semantics.  At the very least that requires
> careful analysis.
> 

Yes, true. The one previous implementation of hidden directories that I
am familiar with, had many special case restrictions such as cannot
rename or link to hidden directories, cannot add/delete "multilevelness"
to a directory if not empty, cannot create anything inside multilevel
directories except hidden intermediate directories, etc, etc. For us,
that just adds to the unsuitability of that approach.

(
> 
> 	unionfs: sorry, nowhere near ready for merge.  There is a lot
> of nasty corner cases in all implementations I've seen and that's not
> easy to overcome.
> 

Understood.

> 
> 	namespaces: why do we need these guys to be subdirectories of
> /tmp, in the first place?  Unlike the mechanisms based on intermediate
> subdirectories, there's nothing to require putting this tmp-for-that-context
> anywhere near the same filesystem that holds /tmp.  Moreover, in a lot
> of cases you most certainly do *not* want that to happen - e.g. when your
> policy demands /tmp on encrypted physically separate device for given
> context.
> 	What's wrong with simply having a list of pairs (what,from where)
> for given context (it might be explicitly set, might be generated, might
> include standard chunks with simple substitution, whatever) and simply
> do these bindings when you set up namespace for your session?
> 	That would avoid a lot of complications in the proposed scheme and
> make it much more flexible (hell, the first and obvious application has
> that list consisting of one pair - /tmp:~/tmp ;-)  All issues with visibility
> of original directories are solved the same way on per-context basis.
> 

True. I will look into this further, but I do see your point. I can't think
of a reason that would require that per-context directories have to be
subdirectories of the polyinstantiated directory.

> 	As far as catching all login-style programs, etc. is concerned,
> I think we all agree that libpam is the right layer for that.  With
> unshare(2) it's not a problem.
> 

Ok, thanks. I will send the patch to you and fsdevel after 2.6.12 goes
out.

> 	Newrole considerations *are* serious - note that current directory
> should be treated as an equivalent of open file, so remounts alone are not
> enough.  The same applies to any open file, obviously, but that deserves
> separate attention.  No good suggestions until you guys describe the
> expected behaviour on newrole in more details...
> 

Thanks, I will look into newrole issues and get feedback from lspp and
selinux mailing lists regarding expected behavior.

> 	mount propagation - yes, shared-subtree would cover it.  Main problem
> here is finishing the sifting through $BIGNUM of long threads for sane posts
> and not going bonkers from the amount of nutcases involved ;-/  Nearly
> finished with the former, not sure about the degree of success with the
> latter...
> 

Ok.  Thank you so much for your feedback. For completeness, I will update
the draft document with added negatives and issues surrounding other
approaches. I will come back to redhat-lspp and selinux mailing list with
issues, questions and feedback requests as I migrate Chad Sellers's work
to PAM.

Thanks.

-Janak

P.S. - The draft referred here is a primer document, on polyinstantiated
        directories, that I had sent to Al using the following intro.

--------------------------------------------------------------------------
Hi Al,

Dan Walsh forwarded to us his quoted below email exchange with you re
polyinstantiated file system. I am one of the IBM engineers who is on point
to implement (and upstream) a polyinstantiated mechanism that would
make selinux LSPP compliant.

Just a clarification to Dan's note, myself and Chad Sellers (of NSA) have
been working on implementing polyinstantiated directories using existing
namespace and bindmount features in the kernel. We are not working on
shared-tree proposal that you posted to fsdevel. Shared-tree work, when
available, will add greatly to the usability of our polyinstantiated
directories, but we are not directly working on the shared-tree proposal.

Our approach essentially involves creating a private namespace for users
based on their security context, and bind mounting an appropriate
subdirectory of /tmp on to /tmp. We are currently modifying commands
that establish a session (login, su, gdm, cron, etc) to create a
namespace using clone. That's why when we saw an interest for unshare
system call on fsdevel, we decided to implement that patch (which
was posted to fsdevel yesterday) to see if we can generate broader
interest in it. That system call would help us put our polyinstantiation
mechanism in PAM instead of duplicating it in various commands.

You are probably aware of all the polyinstantiation requirements/issues,
but in case you are curious, I am attaching a polyinstantiation primer
document that I wrote up for our internal team. As you can see, using
namespaces and bind mounts is our preferred method for providing
polyinstantiation. unshare will help us, but we are not dead in the
water without it. Similarly, without shared-trees we can meet the
technical requirements for certification, but usability in real
customer situations would be degraded.

Thanks.

-Janak