Re: POSIX

[Leonardo Lopes Pereira]

On Wed, 26 Oct 2005 14:33:08 -0400
"Jonathan S. Shapiro" <address@hidden> wrote:

> On Wed, 2005-10-26 at 19:55 +0200, Bas Wijnen wrote:
> > On Wed, Oct 26, 2005 at 11:30:39AM -0400, Jonathan S. Shapiro wrote:
> > > On Wed, 2005-10-26 at 11:06 +0200, Bas Wijnen wrote:
> > > > No, not as alternative.  Programs which need a POSIX box to run should 
> > > > still
> > > > be allowed to use all the cool Hurd features directly.
> > > 
> > > This would be very very pleasant. Unfortunately, it is very difficult to
> > > achieve. The difficulty comes when you allow the insecure subsystem to
> > > access things like your local files, which you want to protect.
> > 
> > That's what the POSIX box is for.  When the process makes POSIX calls, they
> > will return as if it has access to a complete filesystem.  But in fact, it
> > only accesses its own jail.  However, the jail does not prevent the process
> > from making library/system calls to services which all Hurd processes (also
> > non-POSIX) can access.
> 
> Then how is it a jail?
> 
> It sounds like we may be talking past each other. Let me use a concrete
> scenario. I imagine from your description that I might have a protected
> non-POSIX home directory, I might start up a POSIX jail, and I might
> give that jail read-only access to my home directory. Personally I think
> this would be unwise, but let me set aside my reservations for a moment.
> 
> I think you are proposing that as long as (a) the access is read-only
> and (b) the POSIX subsystem is in fact a jail, then I should be okay.
> And this does seem plausible.
> 
> Here is the first difficulty I anticipate:
> 
> The next move is that somebody decides to open up a network port for the
> jail. For example, they wish to run firefox inside the jail.
> Unfortunately, they forget that the POSIX jail has read-only access to
> the home directory. All of your files are now disclosed to the world.
> 
> I see that both things are desirable, but I am not clear how to safely
> manage them in a user-sensible way. Note that turning off home directory
> before opening the network port is NOT good enough!
> 
> Here is a second difficulty:
> 
> My home directory isn't really a file system. It is a mapping from
> strings (the filenames) to capabilities. These capabilities do not name
> files. They name objects implemented by servers. One of these servers
> may be the file server, but at the kernel level of abstraction we do not
> know that.
> 
> The problem here is that you wanted read-only file system access. In
> order to enforce this, we can either:
> 
>   1. Enforce it conservatively, which would preclude letting the POSIX
>      box talk to servers, or
>   2. Have a list of servers we "trust" to implement the "read-only"
>      restriction correctly, or
>   3. Allow confined subsystems that are "clone on open".
> 
> Possibly there are other variations that would work. I'm only trying to
> point out that enforcing a read-only restriction in a system consisting
> of active objects can be a tricky thing to get right.
> 
> shap
> 
> 
> 
> _______________________________________________
> L4-hurd mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/l4-hurd

The unique way to have secure software is creating software in a secure way 
(or, at least, using secure resources). So, I think that to turn this new 
desing able to run POSIX programs is creating a set of libraries that 
"convert", when possible, POSIX features on 'GNU' features. When this is not 
possible, we will need to send a patch to turn it able to run on POSIX and on 
GNU.

-- 
leonardolopespereira at gmail.com

GNU Privacy Guard (GPG)
ID da chave: 83E8AFBF | servidor: keys.indymedia.org
gpg --keyserver keys.indymedia.org --recv-keys 83E8AFBF

pgpRsEhP1NcXG.pgp
Description: PGP signature