init in a jail

[James Gritton]

On 2019-02-11 11:15, Bjoern A. Zeeb wrote:
> On 11 Feb 2019, at 17:23, James Gritton wrote:
> 
>> On 2019-02-11 08:48, Michael W. Lucas wrote:
>>> Sadly, my google-fu has turned up thousands of man pages but no real
>>> discussion on this.
>>> 
>>> According to init(8), you can run init inside a jail.
>>> 
>>>      If init is run in a jail, the security level of the "host 
>>> system" will
>>>      not be affected.  Part of the information set up in the kernel 
>>> to support
>>>      a jail is a per-jail security level.  This allows running a 
>>> higher
>>>      security level inside of a jail than that of the host system.  
>>> See
>>>      jail(8) for more information about jails.
>>> 
>>> 
>>> If you actually try, though, the jail dies:
>>> 
>>> storm~;jail -vc loghost
>>> loghost: run command: /sbin/ifconfig jailether inet 198.51.100.225 
>>> netmask
>>> 255.255.255.255 alias
>>> loghost: run command: /sbin/mount -t devfs -oruleset=4 . 
>>> /jail/loghost/dev
>>> loghost: run command: logger trying to start jail loghost...
>>> loghost: jail_set(JAIL_CREATE) persist name=loghost 
>>> path=/jail/loghost
>>> host.hostname=loghost.mwl.io ip4.addr=19 8.51.100.225
>>> loghost: created
>>> loghost: run command in jail: /sbin/init
>>> jail: loghost: /sbin/init: failed
>>> loghost: removed
>>> loghost: run command: /sbin/umount /jail/loghost/dev
>>> loghost: run command: /sbin/ifconfig jailether inet 198.51.100.225 
>>> netmask
>>> 255.255.255.255 -alias
>>> 
>>> Is that init(8) text left over from an earlier jail incarnation? Or 
>>> is
>>> there some other way to run init in a jail?
>>> 
>>> And WHY would you run init in a jail?
>> 
>> Interesting - I wonder how long it's been since init worked inside 
>> jails.  From the look of your error messages, probably not since devfs 
>> started being used.  I wasn't even aware the init(8) had anything to 
>> say on the matter, but it's clearly erroneous.
> 
> Ken Smith added that message to init(8) 15 years ago and from the
> sounds of it, I think it was more related to securelevels.
> 
> 
> 
>> AS to why it would be good to have a per-jail init, there would be a 
>> few advantages.  Orphaned processes could then reparent to the jail's 
>> init instead of the real init, and the jail root could easily reboot 
>> jails. Doing it right would require presenting jailed init as pid 1, 
>> but that's not really very hard.
> 
> It’s not just PID 1 but yeah;  I have open reviews (which I should
> update) from the vps branch to do a virtualised pid space, real init
> to jails along with it, console, and then init would also manage ttys,
> ..  I need to work on the management bits from the host side to make
> it a real thing (ps, kill, etc. to work with a (jid, pid) combination
> as jexec won’t work anymore (possible collisions etc).  But that’s
> unrelated to this thread.

I was just talking the easy part!  Your project has some phenomenal 
ramifications, but it's also possible to just slide in virtual init on 
its own without the rest - I used to do that back when I was running 
jail-ish containers of my own.  I'd been tempted every now and then to 
add it to jails, but now that you've got something so much bigger, it 
makes sense just to sit back and watch :-).

- Jamie