Re: Hierarchical Jails
Am 27.11.2015 um 08:54 schrieb "Carsten Bäcker":
Sorry... something's wrong with GMX webmailer. Secont time this
happens.
Hi Hackers,
i'm running into problems creating hierarchical jails.
First of all: this is my first try with *hierarchical* jails (in favor
of creating a bunch of VMs for software-testing).
I aliased lo0 with 127.0.1.1 - 127.0.1.3
--- HOST jail.conf ---
exec.start = "/bin/sh /etc/rc";
exec.stop = "/bin/sh /etc/rc.shutdown";
exec.clean;
mount.devfs;
persist;
allow.socket_af=1;
allow.raw_sockets=1;
path = "/usr/local/jails/$name";
mount.fstab = "/usr/local/jails/fstab.$name";
core {
host.hostname="jail_core";
children.max=2;
ip4.addr =
ue0|192.168.42.90,lo0|127.0.1.1,lo0|127.0.1.2,lo0|127.0.1.3;
}
--- "jail_core" jail.conf ---
exec.start = "/bin/sh /etc/rc";
exec.stop = "/bin/sh /etc/rc.shutdown";
exec.clean;
mount.devfs;
persist;
path = "/usr/local/jails/$name";
mount.fstab = "/usr/local/jails/fstab.$name";
dev1 {
host.hostname="jail_dev1";
ip4.addr = lo0|127.0.1.1;
}
jail_core starts up fine, but "children.max" seems to have no effect
when checked within the jail.
root@jail_core:/ # sysctl security.jail.param.children
security.jail.param.children.max: 0
security.jail.param.children.cur: 0
I'm not sure if this is related to the following problem, but when i
try to create a child-jail in this jailed environment i run into the
following error.
root@jail_core:/ # jail -c dev1
ifconfig: ioctl (SIOCAIFADDR): permission denied
jail: dev1: /sbin/ifconfig lo0 inet 127.0.1.1 netmask 255.255.255.255
alias: failed
What am i doing wrong? Any suggestions?
Unfortunately i didn't find too much information concerning
hierarchical jails.
Running CURRENT -r290973.
Best Regards
Carsten Bäcker
The trouble likes in dev1's ip4.addr specification. "lo0|127.0.1.1"
means that the IP address is 127.0.1.1, and that an alias should be
added on the interface lo0. But dev1 doesn't have permission to add
IP aliases, which is where the "alias: failed" message comes from.
The solution is easy in this case: you've already planned ahead and
created the alias in core (as you should have), so it doesn't need to
be created again. Just change dev1's specification to "ip4.addr =
127.0.1.1".
- Jamie
___
freebsd-jail@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
Re: fdescfs patch for working hierarchical jails
Hi James, others, On 26 Sep 2014, at 21:28, James Gritton ja...@gritton.org wrote: On 9/25/2014 3:40 AM, Ruben van Staveren wrote: Hi, Could a committer have a look at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192951 ? This enables fdescfs in hierarchical jails, would be nice to have this for 10.1 Thanks! Best Regards, Ruben van Staveren This would have to go into current first, and then MFC. Considering 10.1 is getting close to release, I suspect it wouldn't be allowed in. I agree, probably better to do it that way indeed. Also, I'm not sure I'd want to implement this in quite the proposed way: it might suffice (from a security viewpoint) to use the existing allow.mount.devfs for mounting fdescfs. Wouldn’t that be misleading? It would be better to mop up the various pseudofses under the monicker allow.mount.pseudofs. - Jamie - Ruben signature.asc Description: Message signed with OpenPGP using GPGMail
Re: fdescfs patch for working hierarchical jails
On 9/27/2014 6:06 AM, Ruben van Staveren wrote: Hi James, others, On 26 Sep 2014, at 21:28, James Gritton ja...@gritton.org wrote: On 9/25/2014 3:40 AM, Ruben van Staveren wrote: Hi, Could a committer have a look at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192951 ? This enables fdescfs in hierarchical jails, would be nice to have this for 10.1 Thanks! Best Regards, Ruben van Staveren This would have to go into current first, and then MFC. Considering 10.1 is getting close to release, I suspect it wouldn't be allowed in. I agree, probably better to do it that way indeed. Also, I'm not sure I'd want to implement this in quite the proposed way: it might suffice (from a security viewpoint) to use the existing allow.mount.devfs for mounting fdescfs. Wouldn’t that be misleading? It would be better to mop up the various pseudofses under the monicker allow.mount.pseudofs. My thinking is that fdescfs is practically the same as what devfs already offers - just more descriptors in /dev/fd than the basic three. I can't see why allowing one wouldn't be akin to allowing the other. In fact, I fail to understand why it was made a separate filesystem in the first place. Perhaps someone on the sec team will tell me otherwise when I ask (which I ought to do before forging ahead). - Jamie ___ freebsd-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to freebsd-jail-unsubscr...@freebsd.org
Re: fdescfs patch for working hierarchical jails
On 9/25/2014 3:40 AM, Ruben van Staveren wrote: Hi, Could a committer have a look at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192951 ? This enables fdescfs in hierarchical jails, would be nice to have this for 10.1 Thanks! Best Regards, Ruben van Staveren This would have to go into current first, and then MFC. Considering 10.1 is getting close to release, I suspect it wouldn't be allowed in. Also, I'm not sure I'd want to implement this in quite the proposed way: it might suffice (from a security viewpoint) to use the existing allow.mount.devfs for mounting fdescfs. - Jamie ___ freebsd-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to freebsd-jail-unsubscr...@freebsd.org
fdescfs patch for working hierarchical jails
Hi, Could a committer have a look at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192951 ? This enables fdescfs in hierarchical jails, would be nice to have this for 10.1 Thanks! Best Regards, Ruben van Staveren signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Tutorial for Hierarchical Jails?
Without going into the current rc system, which isn't up to the task of hierarchical jails, here's a minimal set of parameters/commands to create hierarchical jails that can still ping: # jail -c name=foo host.hostname=foo allow.raw_sockets children.max=99 ip4.addr=10.20.12.68 persist # jexec foo /bin/csh foo# jail -c name=bar host.hostname=bar allow.raw_sockets ip4.addr=10.20.12.68 persist foo# jexec bar /bin/csh bar# ping gritton.org PING gritton.org (161.58.222.4): 56 data bytes 64 bytes from 161.58.222.4: icmp_seq=0 ttl=54 time=78.344 ms - Jamie Edwin Shao wrote: 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 ja...@freebsd.org mailto:ja...@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 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 ja...@freebsd.org mailto:ja...@freebsd.org mailto:ja...@freebsd.org mailto:ja...@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-li...@lists.zabbadoz.net mailto:bzeeb-li...@lists.zabbadoz.net mailto:bzeeb-li...@lists.zabbadoz.net mailto:bzeeb-li...@lists.zabbadoz.net mailto:bzeeb-li...@lists.zabbadoz.net mailto:bzeeb-li...@lists.zabbadoz.net mailto:bzeeb-li...@lists.zabbadoz.net mailto:bzeeb-li...@lists.zabbadoz.net wrote: On Mon, 28 Sep 2009, Edwin Shao wrote
Re: Tutorial for Hierarchical Jails?
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 ja...@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 ja...@freebsd.orgmailto: ja...@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-li...@lists.zabbadoz.net mailto:bzeeb-li...@lists.zabbadoz.net mailto:bzeeb-li...@lists.zabbadoz.net mailto:bzeeb-li...@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? ___ freebsd-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to freebsd-jail-unsubscr...@freebsd.org
Re: Tutorial for Hierarchical Jails?
Edwin Shao wrote: Hello, Does anyone have a walkthrough for how to get hierarchical jails to work? I've been playing around with it for a couple of days and it simply is not working. I would like to know if anyone has gotten it to work, and if so, how? The error I tend to get within a jail (starting another child jail) is: hyper# ./jail start Configuring jails:. Starting jails: cannot start jail neko: I'm using very basic steps as outlined in http://www.freebsd.org/doc/en/books/handbook/jails-intro.html and I am easily getting the jails to work in the non-jailed highest level system. What I have done to troubleshoot so far: * Installed from scratch 8.0-RC1 ISO, make buildworld from scratch 8.0-RC1 /usr/src. * Created very liberal sysctls. * Tried different combinations of disabling/enabling mounted systems such as devfs, procfs, etc. * Tried modifying different module fs to enable the jail flag. This is under a clean install of 8.0-RC1. I'd be happy to provide additional information for troubleshooting, but I'm not even sure what's going wrong. It'd probably be more helpful for you to just let me know what you did to get it wroking. The main thing you need to do is to set the first-level jail's children.max parameter. It defaults to zero, which doesn't allow a jail to create any child jails (the non-hierarchical default). It sounds like you have everything else you need. - Jamie ___ freebsd-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to freebsd-jail-unsubscr...@freebsd.org
Re: Tutorial for Hierarchical Jails?
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? Thanks, Edwin On Mon, Sep 28, 2009 at 7:35 PM, Jamie Gritton ja...@freebsd.org wrote: Edwin Shao wrote: Hello, Does anyone have a walkthrough for how to get hierarchical jails to work? I've been playing around with it for a couple of days and it simply is not working. I would like to know if anyone has gotten it to work, and if so, how? The error I tend to get within a jail (starting another child jail) is: hyper# ./jail start Configuring jails:. Starting jails: cannot start jail neko: I'm using very basic steps as outlined in http://www.freebsd.org/doc/en/books/handbook/jails-intro.html and I am easily getting the jails to work in the non-jailed highest level system. What I have done to troubleshoot so far: * Installed from scratch 8.0-RC1 ISO, make buildworld from scratch 8.0-RC1 /usr/src. * Created very liberal sysctls. * Tried different combinations of disabling/enabling mounted systems such as devfs, procfs, etc. * Tried modifying different module fs to enable the jail flag. This is under a clean install of 8.0-RC1. I'd be happy to provide additional information for troubleshooting, but I'm not even sure what's going wrong. It'd probably be more helpful for you to just let me know what you did to get it wroking. The main thing you need to do is to set the first-level jail's children.max parameter. It defaults to zero, which doesn't allow a jail to create any child jails (the non-hierarchical default). It sounds like you have everything else you need. - Jamie ___ freebsd-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to freebsd-jail-unsubscr...@freebsd.org
Re: Tutorial for Hierarchical Jails?
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-li...@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? ___ freebsd-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to freebsd-jail-unsubscr...@freebsd.org
Re: Tutorial for Hierarchical Jails?
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-li...@lists.zabbadoz.net mailto:bzeeb-li...@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? ___ freebsd-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to freebsd-jail-unsubscr...@freebsd.org
Re: Tutorial for Hierarchical Jails?
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 ja...@freebsd.org mailto:ja...@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-li...@lists.zabbadoz.net mailto:bzeeb-li...@lists.zabbadoz.net mailto:bzeeb-li...@lists.zabbadoz.net mailto:bzeeb-li...@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? ___ freebsd-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to freebsd-jail-unsubscr...@freebsd.org
Re: Hierarchical jails
Jilles Tjoelker wrote: On Thu, May 14, 2009 at 11:12:50AM -0600, Jamie Gritton wrote: There's still a change to offer your input on the new jails before they go in! OK, given the lack of response so far, it's less still a chance than please?. Current plans are to have this in place for 8.0, with connections to the ongoing Vimage work. Hopefully the silence is approval, and commits will likely be appearing soon. I have not tried this, but I think this patch may allow jailed roots to escape. The problem is that there is only one fd_jdir. The escape would go like: jailed root creates a new jail in a subdirectory, opens its / and sends the fd to a process in the new jail via a unix domain socket. When the process calls fchdir on the fd, it will be able to access .. normally. With nested chroot, or chroot in jail, this is not possible, because fd_jdir always contains the first jail or chroot done and will not allow escaping from it; however, root in a level 2 chroot can escape back to level 1 using chroot. this is the old chroot escape. it is well known and methods exist to stop it. I can not say what is done here, but your post does remind me to add this to the list of things we need to keep in mind. ___ freebsd-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to freebsd-jail-unsubscr...@freebsd.org
Re: Hierarchical jails
There's still a change to offer your input on the new jails before they go in! OK, given the lack of response so far, it's less still a chance than please?. Current plans are to have this in place for 8.0, with connections to the ongoing Vimage work. Hopefully the silence is approval, and commits will likely be appearing soon. I wrote: Here's the first round of hierarchical jails under the new framework. Instead of creds having either a prison or a NULL pointer, they all have a prison pointer with the default being the global prison0 that contains information about the real environment. Jailed root may (if granted permission) create prisons that would be under its place in the hierarchy, but may not alter (or even see) prisons at its level or above. The JID space is flat, i.e. every prison in the system has a unique ID. The prison name space is hierarchical, with jails having dot-separated component names. prison0 contains three fields that were system globals: pr_root, pr_host, and pr_securelevel. I've kept the globals rootvnode and hostname, and take care that when one is changed the other changes too (not yet true for hostname - read on). But I've actually removed the global securelevel, instead forcing people to use securelevel_gt() and securelevel_ge() (or in very rare cases to check prison0.pr_securelevel directly). I chose to do that because while using the global rootvnode and hostname may be incorrect, using the wrong securelevel is, well, insecure. Actually it would be insecure to use the wrong rootvnode too, but I'm not convinced removing that global is worth the headache. Other globals are subsumed into prison0, but they were only ever part of the jail system anyway: the various jail-related permission bits and such administrative things as prisoncount. The prison hierarchy keeps track of restrictions placed on prisons, and will reflect them downward so a child jail is always at least as restricted as its ancestors. It doesn't go the other way though: if a prison's restrictions are loosened, the children stay as they are. This patch doesn't have anything for userland, and hierarchical jails won't work without that patch (because jails don't have permission to create sub-jails by default, and jail(2) can't grant that permission). A userland patch will follow soon, very similar to the version I posted here recently. - Jamie ___ freebsd-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to freebsd-jail-unsubscr...@freebsd.org
Re: Hierarchical jails
Julian Elischer wrote: Jamie Gritton wrote: prison0 contains three fields that were system globals: pr_root, pr_host, and pr_securelevel. I've kept the globals rootvnode and hostname, and take care that when one is changed the other changes too (not yet true for hostname - read on). But I've actually removed the global securelevel, instead forcing people to use securelevel_gt() and securelevel_ge() (or in very rare cases to check prison0.pr_securelevel directly). I chose to do that because while using the global rootvnode and hostname may be incorrect, using the wrong securelevel is, well, insecure. Actually it would be insecure to use the wrong rootvnode too, but I'm not convinced removing that global is worth the headache. not sure why you want to keep hostname a true global It seems to me that it is an eminently virtalizable property. though possible a special hostname might exist for the base system for error messages etc. kind of like V_hostname an G_hostname :) It was mostly for the number of times I saw that global being used - didn't want to upset the order of things too much. I didn't see nearly as much use of securelevel with the advent of securelevel_ge() and securelevel_gt(). But I suppose the G/V_hostname thing has already gotten that ball rolling. There is at least one place that uses the global securelevel directly (i.e. prison0.securelevel). The same could be done for hostnames, which does a pretty good job of pointing out that this is the global hostname being used. Because you're right - the hostname is at the center of of what it means to have a jail identity. Then there's rootvnode, the third global that's superseded by hierarchical jails. I could also remove that, allowing the use of prison0.pr_root for those who need the real root. ___ freebsd-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to freebsd-jail-unsubscr...@freebsd.org
Re: Hierarchical jails
On Thu, May 14, 2009 at 11:12:50AM -0600, Jamie Gritton wrote: There's still a change to offer your input on the new jails before they go in! OK, given the lack of response so far, it's less still a chance than please?. Current plans are to have this in place for 8.0, with connections to the ongoing Vimage work. Hopefully the silence is approval, and commits will likely be appearing soon. I have not tried this, but I think this patch may allow jailed roots to escape. The problem is that there is only one fd_jdir. The escape would go like: jailed root creates a new jail in a subdirectory, opens its / and sends the fd to a process in the new jail via a unix domain socket. When the process calls fchdir on the fd, it will be able to access .. normally. With nested chroot, or chroot in jail, this is not possible, because fd_jdir always contains the first jail or chroot done and will not allow escaping from it; however, root in a level 2 chroot can escape back to level 1 using chroot. -- Jilles Tjoelker ___ freebsd-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to freebsd-jail-unsubscr...@freebsd.org
Re: Hierarchical jails
Jilles Tjoelker wrote: On Thu, May 14, 2009 at 11:12:50AM -0600, Jamie Gritton wrote: There's still a change to offer your input on the new jails before they go in! OK, given the lack of response so far, it's less still a chance than please?. Current plans are to have this in place for 8.0, with connections to the ongoing Vimage work. Hopefully the silence is approval, and commits will likely be appearing soon. I have not tried this, but I think this patch may allow jailed roots to escape. The problem is that there is only one fd_jdir. The escape would go like: jailed root creates a new jail in a subdirectory, opens its / and sends the fd to a process in the new jail via a unix domain socket. When the process calls fchdir on the fd, it will be able to access .. normally. With nested chroot, or chroot in jail, this is not possible, because fd_jdir always contains the first jail or chroot done and will not allow escaping from it; however, root in a level 2 chroot can escape back to level 1 using chroot. Indeed - considering how that was a major design point of jails, I'm not sure how I missed it. .. processing will need to run up the jail tree. No big deal on performance and easily done, but embarrassing not have had that in place already. ___ freebsd-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to freebsd-jail-unsubscr...@freebsd.org
Re: Hierarchical jails
Jamie Gritton wrote: Here's the first round of hierarchical jails under the new framework. Instead of creds having either a prison or a NULL pointer, they all have a prison pointer with the default being the global prison0 that contains information about the real environment. Jailed root may (if granted permission) create prisons that would be under its place in the hierarchy, but may not alter (or even see) prisons at its level or above. The JID space is flat, i.e. every prison in the system has a unique ID. The prison name space is hierarchical, with jails having dot-separated component names. [...] I am glad that you are working on this feature! I added info + links to this patches on wiki http://wiki.freebsd.org/Jails I hope I will have some free time to test it soon. Miroslav Lachman ___ freebsd-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to freebsd-jail-unsubscr...@freebsd.org
Re: Hierarchical jails - any current work?
On Tue, Sep 18, 2007 at 03:03:12PM -0600, James Gritton wrote: I've been doing some work on a hierarchical jail setup, but I've got this nagging feeling it's been done before. Does anyone know of such an existing project? If not, I'll put forward my own code. Something like this: http://garage.freebsd.pl/mljail.README I did it some time ago, and this is one of the feature for new jail implementation with is beeing designed. -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpDoIcQRh5kl.pgp Description: PGP signature
