On Wed, 26 Oct 2005 14:33:08 -0400 "Jonathan S. Shapiro" <[EMAIL PROTECTED]> 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 > [email protected] > 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
pgpiWuGmz3tGK.pgp
Description: PGP signature
_______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
