Re: Call for a hacker.... security.bsd.see_other_uids in jails only

On Fri, 21 May 2004, 12:02+0300, Ruslan Ermilov wrote:

> On Fri, May 21, 2004 at 12:14:19PM +0400, Gleb Smirnoff wrote:
> > On Fri, May 21, 2004 at 10:02:18AM +0200, Pawel Jakub Dawidek wrote:
> > P> Implementation wouldn't be probably too hard, but I can't agree it should
> > P> be committed. We need to know where jail's virtualization ends and I think
> > P> it is too far. Of course it will be cool to have those sysctl on per-jail
> > P> basics, as well as others from security.bsd. tree
> > P> (like security.bsd.suser_enabled), but I'm not sure this is the right way
> > P> to go.
> > P>
> > P> Any other opinions? If someone convince me we should do it, I can do it.
> >
> > A more general solution will be better, but harder to implement: make
> > some sysctl branches (e.g. security.bsd) local per jail, and possibility to
> > change them only from host machine.
> >
> I like the idea of per-jail sysctl MIB trees, e.g.:
>
> jail.<JID>.security.bsd
>
> When jail gets created, the generic sysctl code would traverse
> the primary sysctl tree (excluding the jail. subtree), and copy
> and attach those that have some jail-related flag to the
> jail.<JID>. branch.
>
> Inside the jail, jail.<JID>.security.bsd branch would map to
> just security.bsd.
>
> The generic sysctl code, when it detects it's run within a
> jail, will find a sysctl node "foo.bar", and if it has a
> jail-clone flag set, will remap a query to jail.<JID>.foo.bar.
>
> Whether it's allowed to change a particular sysctl inside
> a jail is another matter.

We are discovering vimage slowly :-)

http://www.tel.fer.hr/zec/BSD/vimage/

-- 
Maxim Konovalov