> On Tue, Jan 28, 2003 at 10:39:33AM -0600, Joseph Guhlin wrote: > > Pardon my ignorance on the whole issue but I'm just a lurker trying to > > understand enough to help out. =) > > I know security on parrot like this would be difficult, and this thread > > is specifically about securing PASM, but what about something like > > FreeBSD's 'jail' command built in? That way, even untrusted code could > > possibly be set(somewhere in the parrot configuration, compile time, > > command line, enviroment, etc...) to be jailed. The man pages are here: > > The fun bit is getting information in and out of the jail. ie. you trust > a module but not one of its derived classes.... Also, you might wish to > note that both jail(2) and chroot(2) need to be called by the super-user.
If it's jail and something gets out then it's not a good jail. To me jail means what you see is what you get. If you trust code in the jail, then you should be ok. > The reason you can't do a jail entirely within Parrot is that the moment > you link to any native code, all bets are off, and you're reliant on > what the kernel allows you to do. Parrot can no longer control it. This is probably out of my league. I'm sure your right on this one. > It seems to me that the linking with native code is going to end up > being one that most people switch on, because it will be necessary > and/or useful in getting anything done. Well, that would mean two parrots, which I think is great. One w/ jail for untested code, one w/o. I see four levels of security: 1. chroot jail where / is the toplevel /parrot. If there needs to be a /usr, then it's /parrot/usr. 2. catching all calls and keeping them in line. For example, there are some opcodes that can't work in "sandbox" mode. 3. Manually checking over all libs that are linked to for safety. Only "safe" (those that can't be used to pick your way out of jail) go into /jail/lib. 4. Many things that I have not thought of, but are known to others. This is probably overly general and simplistic, but I just want to make sure that when we are talking about #2, people don't think that they mean #3 or heaven forbid #4. Fred Ollinger
