Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 1 Oct 2009 21:42:20 +0300
From:      Edwin Shao <edwin.shao@gmail.com>
To:        Jamie Gritton <jamie@freebsd.org>
Cc:        "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>, freebsd-jail@freebsd.org
Subject:   Re: Tutorial for Hierarchical Jails?
Message-ID:  <cf8a6aa50910011142h1cdafe20ve5be1eac5baa626b@mail.gmail.com>
In-Reply-To: <4AC18822.7020705@FreeBSD.org>
References:  <cf8a6aa50909280506g63030d9ft423c42e8c61700d@mail.gmail.com>  <4AC0E5E6.1010700@FreeBSD.org> <cf8a6aa50909281045x47e58e99y92437ffa86c72846@mail.gmail.com>  <20090928180731.M68375@maildrop.int.zabbadoz.net> <cf8a6aa50909281326t72701481ve6b2450e792cd104@mail.gmail.com>  <4AC12798.8070308@FreeBSD.org> <cf8a6aa50909281707t726cab37ieec29ca21303ae45@mail.gmail.com>  <4AC18822.7020705@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
The base system has allow_raw_sockets, the first level jail also has
allow_raw_sockets and has the exact same configuration as the base system (I
use puppet to manage config files.) I can't set allow_raw_sockets anyway for
the second-level jail without manually invoking the jail command.

On Tue, Sep 29, 2009 at 7:08 AM, Jamie Gritton <jamie@freebsd.org> wrote:

> Does the base system have security.jail.allow_raw_sockets=1? You need to
> have that, or set the jail's allow.raw_sockets. You can't set the jail's
> permissions from within the jail itself. If you have multiple jail
> levels, then both jails need to allow raw sockets - a jail can't allow a
> child jail to do what it can't do itself.
>
> - Jamie
>
>
> Edwin Shao wrote:
>
>> One other thing that is odd: hierarchical jails don't seem to inherit some
>> sysctls such as allow_raw_socket.
>>
>> In the host (jail), rc.conf has jail_set_allow_raw_sockets="YES" and
>> sysctl.conf has "security.jail.allow_raw_sockets=1", but no child jail can
>> ping out:
>> neko# ping google.com <http://google.com>;
>> ping: socket: Operation not permitted
>>
>> What is happening in this case?
>> Thank you for your time again.
>>
>>
>> On Tue, Sep 29, 2009 at 12:16 AM, Jamie Gritton <jamie@freebsd.org<mailto:
>> jamie@freebsd.org>> wrote:
>>
>>    The sysctls not only don't get written to, they don't have any useful
>>    information to read either. They only describe the existence and format
>>    of the various jail parameters. Sorry, but there;s no way to set a
>>    default children.max parameter or inherit it from the parent. We've
>>    decided to set the default to the most secure/restrictive in many
>> cases.
>>    Once we've come up with a new jail configuration interface, this won't
>>    be such a hassle.
>>
>>    The devfs errors are probably something that will have to be addressed
>>    in a later revision - I haven't looked in the devfs direction so I'm
>> not
>>    sure about that. The mount error may be related to the first jail's
>>    allow.mount parameter (whose default comes from
>>    security.jail.mount_allowed).
>>
>>    - Jamie
>>
>>    Edwin Shao wrote:
>>
>>        Thanks, that worked for me.
>>
>>        * Using jail to change children.max on the parent does not
>>        affect `sysctl security.jail.param.children.max` in the child.
>>         Also security.jail.param.children.cur never changes either. Not
>>        sure if that's intended behavior.
>>        * Is there any way to persist the
>>        security.jail.param.children.max parameter without entering the
>>        jail command every time? * I get the following output when I
>>        create a jail inside a jail:
>>
>>        hyper ~> ezjail-admin start neko
>>        Configuring jails:.
>>        Starting jails:devfs rule: ioctl DEVFSIO_RGETNEXT: Operation not
>>        permitted
>>        devfs rule: ioctl DEVFSIO_RGETNEXT: Operation not permitted
>>        /etc/rc.d/jail: WARNING: devfs_set_ruleset: you must specify a
>>        ruleset number
>>        devfs rule: ioctl DEVFSIO_SAPPLY: Operation not permitted
>>        ln: log: Operation not permitted
>>        mount: proc : Operation not permitted
>>         neko.
>>
>>        I'm using the same configuration values as in the parent's jail,
>>        which work. Everything seems to work alright inside the jail, so
>>        I assume the errors are safe to ignore?
>>
>>        Thanks again!
>>        - Edwin
>>
>>        On Mon, Sep 28, 2009 at 9:11 PM, Bjoern A. Zeeb
>>        <bzeeb-lists@lists.zabbadoz.net
>>        <mailto:bzeeb-lists@lists.zabbadoz.net>
>>        <mailto:bzeeb-lists@lists.zabbadoz.net
>>        <mailto:bzeeb-lists@lists.zabbadoz.net>>> wrote:
>>
>>           On Mon, 28 Sep 2009, Edwin Shao wrote:
>>
>>               Hi Jamie,
>>               When I try to change the parameter, nothing happens:
>>               rescue /etc> sudo sysctl security.jail.param.children.max=1
>>               security.jail.param.children.max: 0 -> 0
>>
>>               rescue /etc> sudo sysctl security.jail.param.children.max
>>               security.jail.param.children.max: 0
>>
>>               Am I doing this incorrectly?
>>
>>
>>           Yes. It's a parameter to jail(8).  The security.jail.param
>>        sysctls can
>>           be seen as a list of possible options valid to jail(8).  See
>>        man 8 jail
>>           for the exact details.
>>
>>           /bz
>>
>>           --    Bjoern A. Zeeb           What was I talking about and
>>        who are you again?
>>
>>
>>
>>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cf8a6aa50910011142h1cdafe20ve5be1eac5baa626b>