Running Hobbit-4.2 in Ezjail JAIL, OS FreeBSD-6.2 hobbitd does not seem to want to load. Been fighting this one all day :(
Found this thread and applied HOST sysctl.conf http://www.unidata.ucar.edu/support/help/MailArchives/mcidas/msg02324.html
%vi /etc/sysctl.conf kern.ipc.shmmax=536870912
Also from /var/log/hobbit/hobbitlauch.log (trimmed) 2007-04-09 19:56:46 Cannot access checkpoint file /home/hobbit/server/tmp/hobbitd.chk for restore 2007-04-09 19:56:46 Setting up network listener on 0.0.0.0:1984 2007-04-09 19:56:46 Could not get shm of size 262144: Function not implemented 2007-04-09 19:56:46 Cannot setup status channel 2007-04-09 19:56:46 Task hobbitd terminated, status 1
HOST system reports (192.168.222.90):
%sysctl -a |grep shm kern.ipc.shmmax: 536870912 kern.ipc.shmmin: 1 kern.ipc.shmmni: 192 kern.ipc.shmseg: 128 kern.ipc.shmall: 8192 kern.ipc.shm_use_phys: 0 kern.ipc.shm_allow_removed: 0 shm 1 12K - 1
%sysctl -A|grep semm kern.ipc.semmap: 30 kern.ipc.semmni: 40 kern.ipc.semmns: 100 kern.ipc.semmnu: 30 kern.ipc.semmsl: 60
%netstat -na | grep tcp ; netstat -na |grep udp tcp4 0 0 192.168.222.91.22 192.168.222.61.4319 ESTABLISHED tcp4 0 0 192.168.222.91.22 192.168.222.61.4015 ESTABLISHED tcp4 0 52 192.168.222.90.22 192.168.222.61.4005 ESTABLISHED tcp4 0 0 127.0.0.1.25 *.* LISTEN tcp4 0 0 192.168.222.92.25 *.* LISTEN tcp4 0 0 192.168.222.91.25 *.* LISTEN tcp4 0 0 192.168.222.91.22 *.* LISTEN tcp4 0 0 192.168.222.91.3306 *.* LISTEN tcp4 0 0 192.168.222.91.80 *.* LISTEN tcp4 0 0 192.168.222.90.22 *.* LISTEN udp4 0 0 192.168.222.92.514 *.*
JAILed Hobbit reports(192.168.222.91):
$ ps -aux|more USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND hobbit 1272 0.0 1.3 6252 3300 ?? SJ 7:56PM 0:00.07 sshd: hobbit at ttyp1 (sshd) hobbit 1282 0.0 0.4 1372 1008 ?? SsJ 7:56PM 0:00.01 /home/hobbit/server/bin/hobbitlaunch --config=/home/hobbit/ser
$ sysctl -A |grep shm kern.ipc.shmmax: 536870912 kern.ipc.shmmin: 1 kern.ipc.shmmni: 192 kern.ipc.shmseg: 128 kern.ipc.shmall: 8192 kern.ipc.shm_use_phys: 0 kern.ipc.shm_allow_removed: 0 kern.ipc.shmsegs: Format: Length:9984 Dump:0x00000000000000000002000000000000... shm 1 12K - 1
$ less /var/log/hobbit/hobbitlaunch.log 2007-04-09 19:56:46 Loading hostnames 2007-04-09 19:56:46 Loading saved state 2007-04-09 19:56:46 Cannot access checkpoint file /home/hobbit/server/tmp/hobbitd.chk for restore 2007-04-09 19:56:46 Setting up network listener on 0.0.0.0:1984 2007-04-09 19:56:46 Setting up signal handlers 2007-04-09 19:56:46 Setting up hobbitd channels 2007-04-09 19:56:46 Could not get shm of size 262144: Function not implemented 2007-04-09 19:56:46 Cannot setup status channel 2007-04-09 19:56:46 Task hobbitd terminated, status 1
Thanks Don
On Mon, Apr 09, 2007 at 04:59:36PM -0400, Don Munyak wrote:
Running Hobbit-4.2 in Ezjail JAIL, OS FreeBSD-6.2 hobbitd does not seem to want to load.
2007-04-09 19:56:46 Could not get shm of size 262144: Function not implemented 2007-04-09 19:56:46 Cannot setup status channel 2007-04-09 19:56:46 Task hobbitd terminated, status 1
"Function not implemented" is a fairly serious problem. Essentially, the operating system does not have IPC support. FreeBSD does have it, so I suspect this could be caused by your running it in a jail setup.
Indeed, Google turned up this description of restrictions for processes running inside FreeBSD jails:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/jail-restrict...
This very clearly shows that support for IPC using shared memory and semaphores is not supported for jailed processes. There is a "jail_sysvipc_allowed" sysctl setting (defaults to 0 - "off") that might enable IPC support inside the jail; I couldn't quite tell from this webpage.
Regards, Henrik
Thanks Henrik...
I read the link as well as the {prev} page from said link. And then googled the author. OT: I can't beleive the author was in 9th grade when he wrote the article. I am completely amazed and envious
http://www.samag.com/documents/s=1151/sam0105d/0105d.htm
...anyway
I made the change to the HOST sysctl.conf.
security.jail.sysvipc_allowed=1
Current sysctl.conf for HOST system
Uncomment this to prevent users from seeing information about processes that
are being run under another UID.
security.bsd.see_other_uids=0
net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1
net.inet.ip.check_interface=1 net.inet.tcp.recvspace=32768 net.inet.tcp.sendspace=32768 net.inet.tcp.syncookies=0 net.inet.icmp.bmcastecho=0 net.inet.icmp.maskrepl=0 net.inet.icmp.icmplim=200 security.jail.sysvipc_allowed=1 security.jail.allow_raw_sockets=1 kern.ipc.shmmax=536870912
%sysctl -A -d |grep jail {listing human readable desc} security.jail.set_hostname_allowed:Processes in jail can set their hostnames security.jail.socket_unixiproute_only:Processes in jail are limited to creating UNIX/IPv4/route sockets only security.jail.sysvipc_allowed:Processes in jail can use System V IPC primitives security.jail.enforce_statfs:Processes in jail cannot see all mounted file systems security.jail.allow_raw_sockets:Prison root can create raw sockets security.jail.chflags_allowed:Processes in jail can alter system file flags security.jail.list:List of active jails security.jail.jailed:Process in jail?
%sysctl -A | grep jail security.jail.set_hostname_allowed:1 security.jail.socket_unixiproute_only:1 security.jail.sysvipc_allowed:1 security.jail.enforce_statfs:2 security.jail.allow_raw_sockets:1 security.jail.chflags_allowed:0 security.jail.list:Format:S Length:2584 Dump:0x01000000020000002f7573722f6a6169... security.jail.jailed:0
hobbitd now loads and website appears functional. I haven't yet configured any host systems.
Aside from the obvious "Processes in jail can use System V IPC primitives", what does this mean in terms of security. I understand that should a jail get hacked, the hacker can use system V IPC primitives. How and to what extent?
Thanks so much for your help
Don
Hi Don,
On Tue, Apr 10, 2007 at 09:28:56AM -0400, Don Munyak wrote:
Aside from the obvious "Processes in jail can use System V IPC primitives", what does this mean in terms of security. I understand that should a jail get hacked, the hacker can use system V IPC primitives. How and to what extent?
I'm not very familiar with FreeBSD, so you're probably better off asking someone else. But I'd suspect that the SysV IPC mechanisms may not be constrained inside the jail, so that a jail'ed process can connect to a shared memory segment which was created outside the jail.
And likewise, a process outside the Hobbit jail may be able to access the shared memory segments that Hobbit sets up inside the jail.
You can try this: Start Hobbit inside the jail. From outside the jail, try running (as root) "ipcs -m". If this lists a handful of shared memory segments owned by the Hobbit userid, then the shared memory that Hobbit has setup inside the jail is also visible outside the jail.
From a security perspective, I guess the main risk involved is that of having a channel that can be used to leak information via a shared memory segment from inside the jail to outside the jail.
Regards, Henrik
On 4/11/07, Henrik Stoerner <henrik at hswn.dk> wrote:
Hi Don,
On Tue, Apr 10, 2007 at 09:28:56AM -0400, Don Munyak wrote:
Aside from the obvious "Processes in jail can use System V IPC primitives", what does this mean in terms of security. I understand that should a jail get hacked, the hacker can use system V IPC primitives. How and to what extent?
I'm not very familiar with FreeBSD, so you're probably better off asking someone else. But I'd suspect that the SysV IPC mechanisms may not be constrained inside the jail, so that a jail'ed process can connect to a shared memory segment which was created outside the jail.
And likewise, a process outside the Hobbit jail may be able to access the shared memory segments that Hobbit sets up inside the jail.
You can try this: Start Hobbit inside the jail. From outside the jail, try running (as root) "ipcs -m". If this lists a handful of shared memory segments owned by the Hobbit userid, then the shared memory that Hobbit has setup inside the jail is also visible outside the jail.
From a security perspective, I guess the main risk involved is that of having a channel that can be used to leak information via a shared memory segment from inside the jail to outside the jail.
Thank you. I will check it out and report back to this thread.
Don
participants (2)
-
don.munyak＠gmail.com
-
henrik＠hswn.dk