init in a jail

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

init in a jail

Michael W. Lucas-2
Hi,

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?

Thanks,
==ml



--
Michael W. Lucas https://mwl.io/
author of: Absolute OpenBSD, SSH Mastery, git commit murder,
Immortal Clay, PGP & GPG, Absolute FreeBSD, etc, etc, etc...
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: init in a jail

James Gritton-2
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.

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.

- Jamie
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: init in a jail

Bjoern A. Zeeb-2
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.


/bz
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: init in a jail

James Gritton-2
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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "[hidden email]"