Re: Opening of /dev/pts/3 fails in jail (no such file), but it is visible in ls

[Alexander Leidinger]

Am 2023-09-22 14:02, schrieb Konstantin Belousov:

On Fri, Sep 22, 2023 at 01:44:33PM +0200, Alexander Leidinger wrote:

Hi,

I'm trying to debug an issue with pinentry-tty. The reason is that I 
want to
export a gpg secret key, but it fails when the gpg-agent tries to ask 
for
the PW. An alternative way to export the key works, but the main way 
should
work too. So I took the time now to dig deeper. This is inside a jail, 
I

haven't tried if it is the same effect outside a jail.

With the gpg developer Werner Koch I tried to debug this, and we went 
down

to do a pinentry-wrapper which calls pinentry within ktrace.

The important part is this:
---snip---
79943 pinentry-tty RET   write 1
 79943 pinentry-tty CALL  read(0x3,0x464697e00158,0x3ea)
 79943 pinentry-tty GIO   fd 3 read 7 bytes
   "GETPIN
   "
 79943 pinentry-tty RET   read 7
 79943 pinentry-tty CALL  sigaction(SIGALRM,0x3fee6ca161d0,0)
 79943 pinentry-tty RET   sigaction 0
 79943 pinentry-tty CALL  sigaction(SIGINT,0x3fee6ca161d0,0)
 79943 pinentry-tty RET   sigaction 0
 79943 pinentry-tty CALL
setitimer(ITIMER_REAL,0x3fee6ca16160,0x3fee6ca16140)
 79943 pinentry-tty STRU  itimerval { .interval = {0, 0}, .value = 
{60, 0} }
 79943 pinentry-tty STRU  itimerval { .interval = {0, 0}, .value = {0, 
0} }

 79943 pinentry-tty RET   setitimer 0
 79943 pinentry-tty CALL  open(0x46469782c020,0)
 79943 pinentry-tty NAMI  "/dev/pts/3"
 79943 pinentry-tty RET   open -1 errno 2 No such file or directory
 79943 pinentry-tty CALL  write(0x4,0x3fee6ca16420,0x36)
 79943 pinentry-tty GIO   fd 4 wrote 54 bytes
   "ERR 83886179 Verarbeitung wurde abgebrochen "
 79943 pinentry-tty RET   write 54/0x36
 79943 pinentry-tty CALL  write(0x4,0x3fee6dd96326,0x1)
 79943 pinentry-tty GIO   fd 4 wrote 1 byte
---snip---

The file exists and I see it inside the jail:
---snip---
% ll /dev/pts/3
crw--w  1 netchild tty 0x180 22 Sep. 12:44 /dev/pts/3
---snip---

The corresponding code is here:

https://github.com/gpg/pinentry/blob/master/tty/pinentry-tty.c#L547


The ttyname comes from the env (set via "export GPG_TTY=$(tty)") set 
in my
.zshenv when logging in (ssh to host, jexec into jail, "su - netchild" 
->

.zshenv -> GPG_TTY is set).

If I do the same via ssh to this account, a new PTS is allocated and 
this

works.

So clearly, the jail is restricting the access to the pts which was
allocated on the host side instead of the jail side.

On one hand this is understandable, as it was not created inside the 
jail.
On the other hand the expectation is if I see the pts inside the jail, 
I
should be able to access it. I can see it with ls, but I can not open 
it

with open(). There is a mismatch.

The first question which comes to my mind now is, what the bug is... 
is it a
bug that it is visible in ls, or is it a bug that I can not open it? 
What is

the reason for the unexpected behavior I see?

Both actions behave as expected:
- visibility is governed by devfs rules, it operates on names of the
  devfs nodes
- opening pty requires corresponding privileges.

So everything works as expected.


Everything works as technically implemented according to the rules of 
the underlying technology... and you have adapted your expectations to 
the underlying technology.


From a human point of view who is not aware of the underlying 
technology, there is a mismatch and it does not work as expected. We 
could adapt the expectation of our users, by documenting this behavior 
in e.g. pts(4) and or jexec(8) including a way how to login to a jail 
from the host in a way which provides a good pty. Or we could adapt the 
technology, to adapt to the expectations of users. The first one is 
surely easy. The second one may be desirable.


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


signature.asc
Description: OpenPGP digital signature

Opening of /dev/pts/3 fails in jail (no such file), but it is visible in ls

[Alexander Leidinger]

Hi,

I'm trying to debug an issue with pinentry-tty. The reason is that I 
want to export a gpg secret key, but it fails when the gpg-agent tries 
to ask for the PW. An alternative way to export the key works, but the 
main way should work too. So I took the time now to dig deeper. This is 
inside a jail, I haven't tried if it is the same effect outside a jail.


With the gpg developer Werner Koch I tried to debug this, and we went 
down to do a pinentry-wrapper which calls pinentry within ktrace.


The important part is this:
---snip---
79943 pinentry-tty RET   write 1
 79943 pinentry-tty CALL  read(0x3,0x464697e00158,0x3ea)
 79943 pinentry-tty GIO   fd 3 read 7 bytes
   "GETPIN
   "
 79943 pinentry-tty RET   read 7
 79943 pinentry-tty CALL  sigaction(SIGALRM,0x3fee6ca161d0,0)
 79943 pinentry-tty RET   sigaction 0
 79943 pinentry-tty CALL  sigaction(SIGINT,0x3fee6ca161d0,0)
 79943 pinentry-tty RET   sigaction 0
 79943 pinentry-tty CALL  
setitimer(ITIMER_REAL,0x3fee6ca16160,0x3fee6ca16140)
 79943 pinentry-tty STRU  itimerval { .interval = {0, 0}, .value = {60, 
0} }
 79943 pinentry-tty STRU  itimerval { .interval = {0, 0}, .value = {0, 
0} }

 79943 pinentry-tty RET   setitimer 0
 79943 pinentry-tty CALL  open(0x46469782c020,0)
 79943 pinentry-tty NAMI  "/dev/pts/3"
 79943 pinentry-tty RET   open -1 errno 2 No such file or directory
 79943 pinentry-tty CALL  write(0x4,0x3fee6ca16420,0x36)
 79943 pinentry-tty GIO   fd 4 wrote 54 bytes
   "ERR 83886179 Verarbeitung wurde abgebrochen "
 79943 pinentry-tty RET   write 54/0x36
 79943 pinentry-tty CALL  write(0x4,0x3fee6dd96326,0x1)
 79943 pinentry-tty GIO   fd 4 wrote 1 byte
---snip---

The file exists and I see it inside the jail:
---snip---
% ll /dev/pts/3
crw--w  1 netchild tty 0x180 22 Sep. 12:44 /dev/pts/3
---snip---

The corresponding code is here:
https://github.com/gpg/pinentry/blob/master/tty/pinentry-tty.c#L547

The ttyname comes from the env (set via "export GPG_TTY=$(tty)") set in 
my .zshenv when logging in (ssh to host, jexec into jail, "su - 
netchild" -> .zshenv -> GPG_TTY is set).


If I do the same via ssh to this account, a new PTS is allocated and 
this works.


So clearly, the jail is restricting the access to the pts which was 
allocated on the host side instead of the jail side.


On one hand this is understandable, as it was not created inside the 
jail. On the other hand the expectation is if I see the pts inside the 
jail, I should be able to access it. I can see it with ls, but I can not 
open it with open(). There is a mismatch.


The first question which comes to my mind now is, what the bug is... is 
it a bug that it is visible in ls, or is it a bug that I can not open 
it? What is the reason for the unexpected behavior I see?


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


signature.asc
Description: OpenPGP digital signature

Re: What's going on with vnets and epairs w/ addresses?

[Alexander Leidinger]

Quoting "Bjoern A. Zeeb"  (from Tue, 13 Dec 2022  
23:03:42 + (UTC)):



Hi,

I have used scripts like the below for almost a decade and a half
(obviously doing more than that in the middle).  I haven't used them
much lately but given other questions I just wanted to fire up a test.

I have an end-November kernel doing the below my eapirs do not come back
to be destroyed (immediately).
I have to start polling for the jid to be no longer alive and not in
dying state (hence added the jls/ifconfig -l lines and removed the
error checking from ifconfig destroy).  That seems sometimes rather
unreasonably long (to the point I give up).

If I don't configure the addresses below this isn't a problem.

Sorry I am confused by too many incarnations of the code; I know I once
had a version with an async shutdown path but I believe that never made
it into mainline, so why are we holding onto the epairs now and not
nuking the addresses and returning them and are clean?


Kristof, isn't this (epair destruction in jails) one of the issues you  
looked at? Sorry if I remember incorrectly.


What I have in my jails-shutdown is to do an "ifconfig $epair_in_jail  
-vnet $jail; sleep 2; ifconfig $epair destroy". With this I don't see  
any issues, Everything is cleaned up when the stop finishes.


Bye,
Alexander.


It's a bit more funny; I added a twiddle loop at the end and nothing
happened.  So I stop the script and start it again and suddenly another
jail or two have cleaned up and their epairs are back.  Something feels
very very wonky.  Play around with this and see ... and let me know if
you can reproduce this...  I quite wonder why some test cases haven't
gone crazy ...

/bz


#!/bin/sh

set -e
set -x

js=`jail -i -c -n jl host.hostname=left.example.net vnet persist`
jb=`jail -i -c -n jr host.hostname=right.example.net vnet persist`

# Create an epair connecting the two machines (vnet jails).
ep=`ifconfig epair create | sed -e 's/a$//'`

# Add one end to each vnet jail.
ifconfig ${ep}a vnet ${js}
ifconfig ${ep}b vnet ${jb}

# Add an IP address on the epairs in each vnet jail.
# XXX Leave these out and the cleanup seems to work fine.
jexec ${js}  ifconfig ${ep}a inet  192.0.2.1/24
jexec ${jb}  ifconfig ${ep}b inet  192.0.2.2/24

# Clean up.
jail -r ${jb}
jail -r ${js}

# You want to be able to remove this line ...
set +e

# No epairs to destroy with addresses configured; fine otherwise.
ifconfig ${ep}a destroy
# echo $?

# Add this is here only as things are funny ...
# jls -av jid dying
# ifconfig -l

# end


--
Bjoern A. Zeeb r15:7



--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpsDY8yfJFrW.pgp
Description: Digitale PGP-Signatur

Re: Auto-jailing of services - 2nd implementation

[Alexander Leidinger]

Quoting FreeBSD User  (from Sun, 15 May 2022  
12:49:06 +0200):



On Sun, 03 Apr 2022 21:48:42 +0200
Alexander Leidinger  wrote:


Hi,

attached is a new implementation of service jails (auto-jailing of
services). This one now supports rc command prefixes (e.g. onestart)
and I tested it in nested jails. The benefit of auto-jailing services
is, that you can apply some restrictions to services (and what other
processes it may see). If your service requires access to network but
not sysvipc, and it doesn't run as root, it can be limited to network
access with or without raw sockets, filesystem-permitted files, and
doesn't see other processes on the system.

For a few services I have added the required "svcj-config" in the
start scripts (e.g. network access for syslog by setting
syslogd_svj_options=net_basic).

Possible svcj config options for service jails:
+   netv4)
+   _svcj_cmd_options="ip4=inherit
allow.reserved_ports ${_svcj_cmd_options}"
+   ;;
+   netv6)
+   _svcj_cmd_options="ip6=inherit
allow.reserved_ports ${_svcj_cmd_options}"
+   ;;
+   net_basic)
+   _svcj_cmd_options="ip4=inherit 
ip6=inherit
allow.reserved_ports ${_svcj_cmd_options}"
+   ;;
+   net_raw)
+   _svcj_cmd_options="allow.raw_sockets
${_svcj_cmd_options}"
+   ;;
+   net_all)
+   _svcj_cmd_options="allow.socket_af
allow.raw_sockets allow.reserved_ports ip4=inherit ip6=inherit  
${_svcj_cmd_options}"

+   ;;
+   sysvipc)
+   _svcj_cmd_options="sysvmsg=inherit
sysvsem=inherit sysvshm=inherit  ${_svcj_cmd_options}"
+   ;;
+   mlock)
+   _svcj_cmd_options="allow.mlock
${_svcj_cmd_options}"
+   ;;
+   vmm)
+   _svcj_cmd_options="allow.vmm
${_svcj_cmd_options}"

By setting syslogd_svcj="YES" in rc.conf your syslogd will be started
in a jail which inherits the full filesystem and the ipv4 and ipv6
addresses of the parent.

It would be nice if interested people could experiment a little bit
with this, e.g. adding name_svcj_options="X Y" from above and
name_svcj="YES" into rc.conf and see if it works. Note, doing that for
sshd doesn't make sense in the generic case, it wouldn't see your
jails. It may make sense for services.

Any kind of feedback and tested name_svcj_options submissions welcome...

Bye,
Alexander.



Hello Alexander Leidinger,

is this really interesting feature already part of recent CURRENT rc  
subsystem or do I


No.

have to "patch" CURRENT with the rc script provided by some place  
first to obtain the

functionality you are talking here about?


The patch was supposed to be attached to the mail you quoted. A more  
recent patch (now with docu in the rc.conf man page) is attached to  
this email (rc.subr + service command + man pages + a few services ->  
"grep diff svcjails.diff" for the list of OS services which can enable  
without research about the svcj_options). At least /etc/rc.subr and  
/usr/sbin/service need to be patched (respectively a  
buildworld+installworld).



Thanks in advance and kind regards

O. Hartmann

p.s. would it be possible toput as service with a dedicated network  
interfacing (say,
jailed vnet/vlan, forinstance an asterisk service running on a small  
router appliance, as

we do in our projects?).


This will use the networking of the host. This is really automatic  
stuff, no additional network interface (all what the hosts sees is  
also available in the service-jail), no dedicated directory/filesystem  
area (as if it runs unjailed). All is used from the host. The  
additional security this provides is the limit of what the process is  
allowed to do in the kernel and the namespace isolation. So you could  
prevent sysvipc access. You could restrict it to ipv6 even if ipv4 is  
configured. You wouldn't see processes outside of the service jail  
even if running as root. If you want more advanced things, you need to  
create a jail on your own. Parts of what service jails do, could be  
done with capabilities (sometimes even with more restrictions), but  
this needs support inside the application for capabilities, whereas  
service jails do not need changes to the applicatio

Auto-jailing of services - 2nd implementation

[Alexander Leidinger]

Hi,

attached is a new implementation of service jails (auto-jailing of  
services). This one now supports rc command prefixes (e.g. onestart)  
and I tested it in nested jails. The benefit of auto-jailing services  
is, that you can apply some restrictions to services (and what other  
processes it may see). If your service requires access to network but  
not sysvipc, and it doesn't run as root, it can be limited to network  
access with or without raw sockets, filesystem-permitted files, and  
doesn't see other processes on the system.


For a few services I have added the required "svcj-config" in the  
start scripts (e.g. network access for syslog by setting  
syslogd_svj_options=net_basic).


Possible svcj config options for service jails:
+   netv4)
+	_svcj_cmd_options="ip4=inherit allow.reserved_ports  
${_svcj_cmd_options}"

+   ;;
+   netv6)
+	_svcj_cmd_options="ip6=inherit allow.reserved_ports  
${_svcj_cmd_options}"

+   ;;
+   net_basic)
+	_svcj_cmd_options="ip4=inherit ip6=inherit allow.reserved_ports  
${_svcj_cmd_options}"

+   ;;
+   net_raw)
+   _svcj_cmd_options="allow.raw_sockets 
${_svcj_cmd_options}"
+   ;;
+   net_all)
+	_svcj_cmd_options="allow.socket_af allow.raw_sockets  
allow.reserved_ports ip4=inherit ip6=inherit ${_svcj_cmd_options}"

+   ;;
+   sysvipc)
+	_svcj_cmd_options="sysvmsg=inherit sysvsem=inherit  
sysvshm=inherit  ${_svcj_cmd_options}"

+   ;;
+   mlock)
+   _svcj_cmd_options="allow.mlock 
${_svcj_cmd_options}"
+   ;;
+   vmm)
+   _svcj_cmd_options="allow.vmm 
${_svcj_cmd_options}"

By setting syslogd_svcj="YES" in rc.conf your syslogd will be started  
in a jail which inherits the full filesystem and the ipv4 and ipv6  
addresses of the parent.


It would be nice if interested people could experiment a little bit  
with this, e.g. adding name_svcj_options="X Y" from above and  
name_svcj="YES" into rc.conf and see if it works. Note, doing that for  
sshd doesn't make sense in the generic case, it wouldn't see your  
jails. It may make sense for services.


Any kind of feedback and tested name_svcj_options submissions welcome...

Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF
diff --git a/libexec/rc/rc.d/auditdistd b/libexec/rc/rc.d/auditdistd
index 13cb5d5b69d..3218bd35755 100755
--- a/libexec/rc/rc.d/auditdistd
+++ b/libexec/rc/rc.d/auditdistd
@@ -19,4 +19,7 @@ required_files="/etc/security/${name}.conf"
 extra_commands="reload"
 
 load_rc_config $name
+
+: ${auditdistd_svcj_options:="net_basic"}
+
 run_rc_command "$1"
diff --git a/libexec/rc/rc.d/ftpd b/libexec/rc/rc.d/ftpd
index dc623ea5943..a04c7ce5ee2 100755
--- a/libexec/rc/rc.d/ftpd
+++ b/libexec/rc/rc.d/ftpd
@@ -23,4 +23,7 @@ ftpd_prestart()
 }
 
 load_rc_config $name
+
+: ${ftpd_svcj_options:="net_all"}
+
 run_rc_command "$1"
diff --git a/libexec/rc/rc.d/inetd b/libexec/rc/rc.d/inetd
index aa8ac20aeae..8cf7be5d91e 100755
--- a/libexec/rc/rc.d/inetd
+++ b/libexec/rc/rc.d/inetd
@@ -18,4 +18,7 @@ required_files="/etc/${name}.conf"
 extra_commands="reload"
 
 load_rc_config $name
+
+: ${inetd_svcj_options:="net_basic"}
+
 run_rc_command "$1"
diff --git a/libexec/rc/rc.d/kadmind b/libexec/rc/rc.d/kadmind
index 773b2d0e499..1bdd420e415 100755
--- a/libexec/rc/rc.d/kadmind
+++ b/libexec/rc/rc.d/kadmind
@@ -26,4 +26,7 @@ kadmind_start_precmd()
 }
 
 load_rc_config $name
+
+: ${kadmind_svcj_options:="net_basic"}
+
 run_rc_command "$1"
diff --git a/libexec/rc/rc.d/kdc b/libexec/rc/rc.d/kdc
index c2747ae08ca..11205d6e092 100755
--- a/libexec/rc/rc.d/kdc
+++ b/libexec/rc/rc.d/kdc
@@ -26,4 +26,7 @@ kdc_start_precmd()
 }
 
 load_rc_config $name
+
+: ${kdc_svcj_options:="net_basic"}
+
 run_rc_command "$1"
diff --git a/libexec/rc/rc.d/kpasswdd b/libexec/rc/rc.d/kpasswdd
index a2875bf1515..af7b7a6b9aa 100755
--- a/libexec/rc/rc.d/kpasswdd
+++ b/libexec/rc/rc.d/kpasswdd
@@ -26,4 +26,7 @@ kpasswdd_start_precmd()
 }
 
 load_rc_config $name
+
+: ${kapsswd_svcj_options:="net_basic"}
+
 run_rc_command "$1"
diff --git a/libexec/rc/rc.d/local_unbound b/libexec/rc/rc.d/local_unbound
index 19cb9a6c5c0..7436034495f 100755
--- a/libexec/rc/rc.d/local_unbound
+++ b/libexec/rc/rc.d/local_unbound
@@ -34,6 +34,7 @@ load_rc_config $name
 : ${local_unbound_anchor:=${local_unbound_workdir}/root.key}
 : 

Re: injecting vars into rc-service-scripts at jail-start?

[Alexander Leidinger]

Quoting Jens Schweikhardt  (from Fri, 1 Apr  
2022 14:26:27 +0200 (CEST)):



Identifier confusion? You use _rc_svcs and _rc_svcj in your description.


Typo s/svcs/svcj/ in the explanation.

The diff/code has the vars correct (svcj) and the conditional and the  
setting are close to each other and are "_rc_svcj".


Bye,
Alexander.


--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpG_9UC_ib9o.pgp
Description: Digitale PGP-Signatur

injecting vars into rc-service-scripts at jail-start?

[Alexander Leidinger]

Hi,

I'm overlooking something fundamental it seems...

Context:
I'm working on my auto-jailing of services idea: if the auto-jail is  
enabled, a service like syslog is started inside a jail (which  
inherits the FS and depending on some settings also inherits network  
and other stuff or not).


My previous implementation was using _rc_prefix (jailstart) to denote  
the start of a service inside a jail so that "service XXX start" on a  
host would "service XXX jailstart" inside a jail. This had off course  
issues as there is no infrastructure for multiple prefix like  
onejailstart or jailonestart...


Problem:
Now I try to find a way to do it without a prefix, and the first thing  
which comes to my mind is to do "jail xxx 'exec.start=/usr/bin/env  
_rc_svcs=jailing /usr/bin/service XXX CMD ARGS'".



My expectation is, that this would set _rc_svcs=jailing for the  
command service XXX CMND args. Having a "set -x" in rc.subr shows  
clearly in the jail-console log, that inside that jail, the variable  
_rc_svcj is not set. Using "-v" for the env command shows in the log  
that it is called and it sets the var and executes the service command  
with syslog start as arguments.


I tried to find some env-cleanup part in rc.subr, which would discard  
all _rc* variables, but if there is something like that I overlooked it.


For a stop, I call "jexec /usr/bin/env _rc_svcj=jailing  
/usr/sbin/service XXX stop args", and it works, so I rather tend to  
believe there is no env-cleanup.


What am I doing wrong so that _rc_svcj is not picked up inside the jail?

So here is my diff between "prefix driven" (= working) and "var  
driven" (var not picked up inside the jail):

---snip---
case "$rc_arg" in
start)
-   if [ "${_rc_prefix}" != jail ]; then
+   if [ "${_rc_svcj}" != jailing ]; then
_return=1
$JAIL_CMD -c  
$_svcj_generic_params $_svcj_cmd_options \
-
exec.start="/usr/sbin/service ${name} jailstart $rc_extra_args" \
-
exec.stop="/usr/sbin/service ${name} jailstop $rc_extra_args" \
+
exec.start="/usr/bin/env _rc_svcj=jailing /usr/sbin/service ${name}  
${rc_arg} $rc_extra_args" \
+
exec.stop="/usr/bin/env _rc_svcj=jailing /usr/sbin/service ${name}  
${rc_arg} $rc_extra_args" \
 
exec.consolelog="/var/log/svcj_${name}_console.log" \
name=svcj-${name}  
&& _return=0

else
# normal start of  
_cmd via _run_rc_doit

---snip---

What set -x tells what it calls:
---snip---
+ /usr/sbin/jail -c 'path=/' mount.nodevfs 'host=inherit'  
'ip4=inherit' 'ip6=inherit' allow.reserved_ports  
'exec.start=/usr/bin/env -v _rc_svcj=jailing /usr/sbin/service -v  
syslogd start  ' 'exec.stop=/usr/bin/env _rc_svcj=jailing  
/usr/sbin/service syslogd start  '  
'exec.consolelog=/var/log/svcj_syslogd_console.log' 'name=svcj-syslogd'

---snip---

Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpl5hIPdeCmy.pgp
Description: Digitale PGP-Signatur

FYI: OCI-compatible runtime for FreeBSD jails

[Alexander Leidinger via freebsd-jail]

Hi,

it seems someone is working on a OCI-compatible runtime for jails:
   https://github.com/samuelkarp/runj

I stumbled over this and thought maybe someone here is interested  
enough to help the author...


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpYiuxyF0b_n.pgp
Description: Digitale PGP-Signatur

Re: /etc/jail.d (or jail.conf.d)

[Alexander Leidinger via freebsd-jail]

Quoting Kyle Evans  (from Thu, 10 Dec 2020  
12:44:27 -0600):



Currently it adds an /etc/jail.d, but the point was raised that we
have a mixture of these with different naming conventions and that
/etc/jail.conf.d may be better -- I'm inclined to agree since


I would prefer jail.conf.d.


Also, while I'm here, would anyone else have interest in joining a
#jail phabricator group if one were to be created?


Yes.

Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpDaBFYyv_f0.pgp
Description: Digitale PGP-Signatur

Re: vnet jail for local only or public access

[Alexander Leidinger via freebsd-jail]

Quoting Ernie Luzar  (from Fri, 17 Jul 2020  
16:31:53 -0400):



Alexander Leidinger wrote:
Quoting Ernie Luzar  (from Fri, 17 Jul 2020  
08:46:07 -0400):


Trying to figure out how to configure a vnet jail so it is  
restricted to only being able to talk to other vnet jails on the  
same host IE: local only vnet jails. As different to being able to  
access the public internet type of vnet jails.


Using the bridge/epair method of connecting vnet jails to the host.
[ based on this how-to ]
https://forums.freebsd.org/threads/vnet-jail-with-public-internet-access-using-the-bridge-epair-method.76071/ It's my understanding that this behavior is controlled by if the hosts interface connected to the public internet is added as a member to the bridge the vnet jails epairXa interfaces were members  
of.


Partly correct. You can also have a setup where your host is  
routing between what you call the public internet and the local  
only vnets.


I tested this on a remote vm and found that it made no difference  
one way or the other if the hosts interface connected to the  
public internet was added as a member to the bridge or not. In  
both cases the vnet jail had public internet access.


It shouldn't, if there is no routing involved.

Please show us "ifconfig -a" and "netstat -rn" of the host.

Bye,
Alexander.



root >netstat -rn4
Routing tables

Internet:
DestinationGatewayFlags Netif Expire
default65.25.48.1 UGS re0
10.0.0.0/8 link#1 U   em0
10.0.10.2  link#1 UHS lo0
10.0.20.0/24   link#5 U  bridge10


You have a routing table entry for the bridge on the host.


10.0.20.2  link#5 UHS lo0
xxx.25.48.0/20 link#2 U   re0
xxx.25.51.0link#2 UHS lo0
127.0.0.1  link#3 UH  lo0
/root >
/root >ifconfig -a


bridge10: flags=8843 metric  
0 mtu 1500

description: qjail-vnet-jail-only-bridge
ether 02:3e:ba:a7:58:0a
inet 10.0.20.2 netmask 0xff00 broadcast 255.255.255.0
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: epair4a flags=143
ifmaxaddr 0 port 6 priority 128 path cost 2000
groups: bridge
nd6 options=1


Your bridge has an IP address.

Both together: I suspect your host is routing between your jail and  
the outside.


If you remove the IP address from the bridge, you should have a  
jails-on-the-bridge-only setup.


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpFJi7GXR4a6.pgp
Description: Digitale PGP-Signatur

Re: vnet jail for local only or public access

[Alexander Leidinger via freebsd-jail]

Quoting Ernie Luzar  (from Fri, 17 Jul 2020  
08:46:07 -0400):


Trying to figure out how to configure a vnet jail so it is  
restricted to only being able to talk to other vnet jails on the  
same host IE: local only vnet jails. As different to being able to  
access the public internet type of vnet jails.


Using the bridge/epair method of connecting vnet jails to the host.
[ based on this how-to ]
https://forums.freebsd.org/threads/vnet-jail-with-public-internet-access-using-the-bridge-epair-method.76071/

It's my understanding that this behavior is controlled by if the  
hosts interface connected to the public internet is added as a  
member to the bridge the vnet jails epairXa interfaces were members  
of.


Partly correct. You can also have a setup where your host is routing  
between what you call the public internet and the local only vnets.


I tested this on a remote vm and found that it made no difference  
one way or the other if the hosts interface connected to the public  
internet was added as a member to the bridge or not. In both cases  
the vnet jail had public internet access.


It shouldn't, if there is no routing involved.

Please show us "ifconfig -a" and "netstat -rn" of the host.

Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpW43lgHjuOi.pgp
Description: Digitale PGP-Signatur

Re: FreeBSD 12.1, vnet jail, and internet access

[Alexander Leidinger via freebsd-jail]

Quoting Dan Langille  (from Tue, 30 Jun 2020  
21:02:24 -0400):



On Tue, Jun 30, 2020, at 8:30 PM, Ernie Luzar wrote:


I think I have determined what your talking about. All the vnet
literature talks about a vnet jail having it's own separate ip stack. I
interpreted this to mean that the vnet jail's stack was connected
directly to the  epair0b / bridge0 / host external interface WITHOUT the
host's firewall knowing anything about that vnet traffic.


FYI, you are not alone.  I have tried to get this working.

A colleague too. We are not novices.

When we get this figured out, it will get documented with a simple
working example.  I promise that.


Think about the host as your hypervisor on steroids.

And with this in mind:
 - Your host has a network stack "N0".
 - Your vnet jail has a seperate network stack "N1".
 - The kernel of the "hypervisor" has a firewall and automatically  
makes it see all physical hardware (remember, it depends upon the  
rules if it does something there or not).
 - Without doing anything, they are not connected (= separate), and  
N1 not even to hardware.
 - On the host you create a virtual network device "bridge0". By  
creating it, it is created in the "namespace of the hypervisor" =  
inside N0. This means the firewall of the host is able to do something  
there, if the rules are setup accordingly.
 - When you create the epair, it is also created in N0, like the  
bridge. On the host all commands you do are operating in the namespace  
of the "hypervisor". The firewall sees both ends of the epair and can  
react to it.

 - When you then give epairXb to N1, you remove it from the N0, which means:
   * you have a P2P connection between N0 and N1
   * the host firewall can not inspect packets on epairXb but still on epairXa
   * you could give an IP to epairXa and have only the host  
communicate with the jail, or do some other things like giving epairXa  
to another jail and have a P2P connection between jails (host firewall  
doesn't see both epair ends anymore) or e.g. the next point
 - Then you connect epairXa to the bridge. If there are other jails  
connected you can have them communicate between each other in this  
virtual network, with the host being able to intercept packets which  
show up on the bridge (it is still in the N0 namespace).

 - If you want to communicate with the outside, you can:
   * connect a network interface (which is inside the namespace of  
the host) to the bridge and the packets leaving the physical device  
have the IP from the jail.
   * give the bridge an IP address and have the host route between  
the bridge and the outside (or have it route between bridge A and  
bridge B but not to the outside).
  - In all the above cases, the bridge(s) and the physical interface  
live in the namespace of N0. As such the firewall of N0 can inspect  
packets there, and you can do NAT (the jail doesn't know what is  
outside, so it makes sense to do the NAT on the host).


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpZUsWR6x0m4.pgp
Description: Digitale PGP-Signatur

Re: Running GUI applications in jails

[Alexander Leidinger via freebsd-jail]

Quoting squiggly foo  (from Mon, 08 Jun 2020  
21:35:23 -0500):



Hi Alexander,

You seem to have a lot of experience with X11 so I'm happy to hear  
your advice.
To answer your first question about where the graphical output needs  
to happen:


I am not sure I am understanding your question, but I am using one  
computer for
all of this.  The Xserver component of X11 is running on this  
computer on the host
(not jailed) and the xclients are the jailed gui applications.  My  
basic problem is to
make sure that jailed gui applications cannot access the keystokes  
of other jailed gui
applications. I guess I am confused by your question (maybe cause  
i'm thinking inside
the box) but what other options are there for running the Xserver  
and Xclients on a single
computer.  Or maybe you are suggesting multiple computers running  
Xservers?  Please
let me know whatever your are thinking as a solution because I am  
open to ideas and

thinking outside the box.


With X11 it doesn't matter if you talk about 1 or multiple computers.  
Within the same network and with a fast enough speed of the network,  
it should work (edge-cases may differ).



Maybe I was also incorrect about running multiple Xservers on the  
same machine on
different ttys but I thought that was an option.  I should check  
with X11 mailing

list.

It's funny that you mention running a Xvnc server inside of a jail  
with each gui
application.  I have actually done that before but I never  
considered it as a possible
option for solving my problem until now that you mentioned it.  So I  
will look into that
more.  My only issue with this: the application that I want jailed  
the most is my
"general browsing" firefox instance used for media websites like  
youtube but I am not
sure how well a 1080p video will look over a vnc connection.  But I  
haven't tested this

idea in awhile.


For your particular use cases you will only know if you test it. As  
you are doing this locally, the "network" speed is a combination of  
the internal bus / CPU / memory speed, and some vnc settings like  
compression may play arole here too, but my gut feeling is, that this  
could work.


I suppose using Xephyr would be a similar yet heavier solution that  
just using your

Xvnc server idea inside each jail.  Would you agree?

I might also look into statically compiling Xpra (if possible) so  
that it at least feels
cleaner that all the dependencies are inside one binary instead of  
all over my system.


I do not know Xephyr or Xpra. I had a very quick look at the  
homepages, and it looks like they are "just" a normal X server (with  
some special features) and use the X11 protocol. As such I do not  
expect that their use will solve your problem (read: I expect that you  
will be able to see keystrokes across all jails).


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpMTV9acSprU.pgp
Description: Digitale PGP-Signatur

Re: Running GUI applications in jails

[Alexander Leidinger via freebsd-jail]

Quoting squiggly foo  (from Fri, 05 Jun 2020  
15:10:05 -0500):


Thanks to Dave for pointing out that my HTML message was stripped. I  
am trying this again.


Hi All,

I'm using FreeBSD as a workstation trying to keep everything as  
lightweight and
segregated as possible. So I am running GUI applications inside a  
jail. My current
solution to this is null mounting the Xorg socket inside the jail  
which allows the
GUI applications to run on the host Xorg without issue.  
Unfortunately this is also
probably the least secure solution as one jail could access the key  
strokes of

another jail through the Xorg on the host.

I researched other solutions to this issue and listed them out below  
with the advantages
and disadvantages. I would like to hear everyones comments/ideas  
because maybe

there are betters ways.


You haven't told where the graphical output needs to happen. The X11  
protocol is distinguishing between the X server (e.g. the component  
which does the output to a grpahics card) and the X client (the  
component which wants to display something e.g. a movie player or  
whatever program you use to produce the output for display). So the  
question here is if you just need to have a X client running there, or  
the X server. You didn't describe the problem you have (I try to find  
out how the problem looks like outside the box), but you describe  
already alternatives in a limited solution sphere (you are inside the  
box and try to find a solution).


[...]

5) Using multiple X servers on different ttys
Using this solution I could group jails according to the level of  
security that they need.
On one Xorg instance say on tty3 I could have my most secure/trusted  
GUI jails and on tty4
I could have less secure less trusted GUI jails. Yes the jails  
inside of the same Xorg instance can
potentially see each others keystrokes but at least I have the lest  
trusted jails in another Xorg

instance.

+Not really that heavy of a solution dependency wise because I  
already have Xorg installed on

the host anyways and just running it multiple times
+I'm assuming the separate Xorg instances don't see each other's  
keystrokes...?

+/- I assume it's clipboard safe between the separate Xorg instances but not
in the same Xorg instance.
-Less flexible of a solution which can affect my workflow, but maybe  
not so bad.


You need to have a graphics card for each instance (I'm not aware that  
two Xorg instances can share the same hardware, but I have never  
looked specially for something like this, so I may have overlooked  
that it can, or it started to be able to do that in the last 10 years.

And yes, they will not see the keystrokes of the other instance.

6) Use Null mounts for the Xorg socket but use a script to 'KILL  
-17' (suspend) all jails and their
processes except for the one jail that I wish to work with at a  
time. Then resume them

afterwards.

+This is a pretty lightweight solution if slightly complex

-A suspended app can still receive keystrokes but will not register  
them until unpaused.
The only assurance I have is that the suspended jailed GUI app  
cannot request to
become the active window (I Think..?) and so as long as I type into  
the correct

non-suspended jail, the other suspended jails cannot see keystrokes.


I wouldn't go that way. Too complicated.

I have patches for FreeBSD which allow to run Xorg in a jail. This  
would be another option as such, but not one which provides more  
security (it's even less, as it opens up the memory of the entire  
machine to this jail, so this jail can see all other jails if you  
write a clever program, I use that in the sense of containerization of  
Xorg and a desktop environment, not for security).


There is also the possibility to run Xvnc in each jail. Each GUI  
program would then connect to the local vnc server instance (or  
better: is started inside the local vnc server instance), and then  
from the system you want to see the output (which can be a local Xorg  
server, or a Windows laptop or an ipad or whatever is able to run a  
vncviewer program) you connect with a vnc viewer to the vnc instance  
of the jail. The applications inside each vnc instance will only see  
keystrokes when the vnc viewer window for this particular instance is  
active. So if you are in the window of vnc viewer instance A the  
instance B will not see keystrokes.


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpLFNcxuexxq.pgp
Description: Digitale PGP-Signatur

panic on epair destroy in current as of r349853, jail related

[Alexander Leidinger via freebsd-jail]

Hi,

I updated from r347365 to r349853. Now I get a panic on epair destroy  
(one end needs to be in a jail, and inside the jail an IP address  
needs to be assigned to the epair. If no ifconfig is used inside the  
jail, there is no panic.


Another user reported something similar (but for him it was enough to  
list the interfaces inside the jail with ifconfig) in PR 234985:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234985

Backtrace (here I also renamed the interface before attaching it to  
the jail, as I detected the issue with interfaces which are renamed):

Fatal trap 9: general protection fault while in kernel mode
cpuid = 13; apic id = 33
instruction pointer = 0x20:0x805f2045
stack pointer   = 0x28:0xfe0159822880
frame pointer   = 0x28:0xfe0159822880
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 43334 (ifconfig)
trap number = 9
panic: general protection fault
cpuid = 13
time = 1562695289
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0159822590
vpanic() at vpanic+0x19d/frame 0xfe01598225e0
panic() at panic+0x43/frame 0xfe0159822640
trap_fatal() at trap_fatal+0x39c/frame 0xfe01598226a0
trap() at trap+0x6c/frame 0xfe01598227b0
calltrap() at calltrap+0x8/frame 0xfe01598227b0
--- trap 0x9, rip = 0x805f2045, rsp = 0xfe0159822880, rbp  
= 0xfe0159822880 ---

strncmp() at strncmp+0x15/frame 0xfe0159822880
ifunit_ref() at ifunit_ref+0x51/frame 0xfe01598228c0
ifioctl() at ifioctl+0x508/frame 0xfe0159822990
kern_ioctl() at kern_ioctl+0x26d/frame 0xfe0159822a00
sys_ioctl() at sys_ioctl+0x15d/frame 0xfe0159822ad0
amd64_syscall() at amd64_syscall+0x23a/frame 0xfe0159822bf0
fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe0159822bf0
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8004690da, rsp =  
0x7fffe448, rbp = 0x7fffe4b0 ---

Uptime: 3h34m59s
Dumping 5294 out of 61352 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%

__curthread () at /space/system/usr_src/sys/amd64/include/pcpu.h:246
246 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n"  
(OFFSETOF_CURTHREAD));
(kgdb) #0  __curthread () at  
/space/system/usr_src/sys/amd64/include/pcpu.h:246

#1  doadump (textdump=1) at /space/system/usr_src/sys/kern/kern_shutdown.c:392
#2  0x8050cf70 in kern_reboot (howto=260)
at /space/system/usr_src/sys/kern/kern_shutdown.c:479
#3  0x8050d3e9 in vpanic (fmt=, ap=)
at /space/system/usr_src/sys/kern/kern_shutdown.c:905
#4  0x8050d123 in panic (fmt=)
at /space/system/usr_src/sys/kern/kern_shutdown.c:832
#5  0x807e758c in trap_fatal (frame=0xfe01598227c0, eva=0)
at /space/system/usr_src/sys/amd64/amd64/trap.c:943
#6  0x807e698c in trap (frame=0xfe01598227c0)
at /space/system/usr_src/sys/amd64/amd64/trap.c:221
#7  
#8  0x805f2045 in strncmp (s1=, s2=,
n=) at /space/system/usr_src/sys/libkern/strncmp.c:44
#9  0x80605d31 in ifunit_ref (name=0xfe0159822a20 "panic_test1b")
at /space/system/usr_src/sys/net/if.c:2434
#10 0x80607ef8 in ifioctl (so=0xf809a1afd368, cmd=3223349536,
data=0xfe0159822a20 "panic_test1b", td=0xf8014c83e5a0)
at /space/system/usr_src/sys/net/if.c:3093
#11 0x8057658d in fo_ioctl (fp=, com=3223349536,
data=0xf800020e2180, active_cred=0x0, td=0xf8014c83e5a0)
at /space/system/usr_src/sys/sys/file.h:333
#12 kern_ioctl (td=0xf8014c83e5a0, fd=3, com=3223349536,
data=0xf800020e2180 "")
at /space/system/usr_src/sys/kern/sys_generic.c:800
#13 0x805762ad in sys_ioctl (td=0xf8014c83e5a0,
uap=0xf8014c83e968) at  
/space/system/usr_src/sys/kern/sys_generic.c:712

#14 0x807e801a in syscallenter (td=0xf8014c83e5a0)
at /space/system/usr_src/sys/amd64/amd64/../../kern/subr_syscall.c:135
#15 amd64_syscall (td=0xf8014c83e5a0, traced=0)
at /space/system/usr_src/sys/amd64/amd64/trap.c:1181
#16 
#17 0x0008004690da in ?? ()
Backtrace stopped: Cannot access memory at address 0x7fffe448

Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpTCQlKxJ5jx.pgp
Description: Digitale PGP-Signatur

Re: Proposal: automatic jailing of services (rc.d/*) [patch]

[Alexander Leidinger via freebsd-jail]

http://www.leidinger.net/FreeBSD/current-patches/rc_svc_jails.diff

--
Send from a mobile device, please forgive brevity and misspellings.

Am 24. Februar 2019 9:48:19 nachm. schrieb Miroslav Lachman <000.f...@quip.cz>:


Alexander Leidinger via freebsd-jail wrote on 2019/02/24 11:00:

[...]


Attached is a proof of concept (only lightly tested with
start/stop/status/restart) so that you can play around with it a little
bit. Please don't focus on the patch. This mail is to seek feedback
about the feature and the quick design so far. To make it explicit, I do
not ask (yet) if and which service to handle like this by default. This
is just the possibility to do something like this.


Interesting idea but patch was stripped by mailing list. Can you put it
online and post the link to it?

Kind regards
Miroslav Lachman




___
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"

Proposal: automatic jailing of services (rc.d/*) [patch]

[Alexander Leidinger via freebsd-jail]

Hi,

Thanks to MWL for his upcoming jail book, it inspired me to come up with this.

Note, I'm not subscribed to freebsd-rc, please keep at least jail@ in  
copy (I'm subscribed there).


I propose to extend the rc system to automatically jail services in a  
light sense (off by default, can be enabled on individual service  
level). The "light sense" means to inherit the entire host (subject to  
options). All programs have still access to the entire filesystem  
(subject to user access permissions). By default no network access.  
Optional access to the hosts IPv4, IPv6, raw sockets or full access to  
all network related parts (see below for "service jail options").  
Similar optional access for sysvipc, mlock and vmm.


The benefit of this approach (aside of being able to prevent network  
and other access if needed (without removing the network at all) when  
it is not enabled) is to put a service and all its children into a  
limited process namespace. A service and its children only see  
themselves but no other processes (a rc script which uses some checks  
in start_cmd to see if some other services/processes are started needs  
to be modified to do the checks in start_precmd, only start_cmd (and  
stop_cmd) is jailed in this design (so far), so that a service can  
check a lot more than what is possible in a jail), and you can kill  
all of those in one go (jail -r svcj-).
Note: this can not be used for services which require access to  
/dev/(k)mem, as this is prohibited in a jail even if the dev-entry is  
there (this means you can not enable this feature for services which  
start X.org to access a graphic card without my patches for X.org in a  
jail). Other hard-coded jail restrictions apply too off course.


As an example for a service which needs network access, it would have  
to have in the rc script

: ${svcname_svcj_options:="net_basic")
to specify that it needs access to IPv4, IPv6 and access to reserved  
ports (see below for more details).
This way the service comes with a default setting and an admin can  
override what the service is allowed to do on his discretion in rc.conf.


There are off course drawbacks, depending on your point of view. If  
you jail sshd, you can only see processes inside the sshd service jail  
via ps/top/..., you can not use commands which require access to  
/dev/(k)mem, you can not start ntpd from such a ssh session, and you  
can not manage (stop/start via rc-means or kill) stuff which is  
running in other service jails, or in short: all hard-coded jail  
restrictions apply. If you stop such a service jail, the current  
implementation removes the entire service jail (after running "service  
stop" inside), so for sshd this would mean that any ssh connection to  
the jailed sshd is killed instead of continuing like in the non  
service jail case. So this is not something which can by enabled by  
default and a careful review of what shall be handled in this way  
needs to be done instead of enabling it blindly.


To enable jailing of a service, an admin has to specify  
svcname_svcj="YES" in rc.conf and optionally options via  
svcname_svcj_options="xxx" if it wants to override the settings/access  
specified in the rc script (or set it if the rc script is not yet  
modified to support service jails).


A rc script shall not enable a service jail by default, it's up to the  
admin to enable that.


This also works in jails, but requires to set children.max to an  
appropriate value for those jails (see jail(8) or MWLs upcoming book  
for more info about hierarchical jails). As we expose  
security.jail.param.children.* in jails, we could add a safetynet  
inside the implementation to not use service jails even if configured,  
when "jailed and cur = max".


RC settings:
_svcj="YES/NO"
_svcj_options="see_below"

service jails options translations:
netv4   -> ipv4=inherit allow.reserved_ports
netv6   -> ipv6=inherit allow.reserved_ports
net_basic   -> ipv4=inherit ipv6=inherit allow.reserved_ports
net_raw -> allow.raw_sockets
net_all		-> allow.socket_af allow.raw_sockets allow.reserved_ports  
ipv4=inherit ipv6=inherit

sysvipc -> sysvmsg=inherit sysvsem=inherit sysvshm=inherit
mlock   -> allow.mlock
vmm -> allow.vmm


Attached is a proof of concept (only lightly tested with  
start/stop/status/restart) so that you can play around with it a  
little bit. Please don't focus on the patch. This mail is to seek  
feedback about the feature and the quick design so far. To make it  
explicit, I do not ask (yet) if and which service to handle like this  
by default. This is just the possibility to do something like this.


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpImyY2Bwmrt.pgp
Description: Digitale PGP-Signatur

Re: enforce_statfs showing leading path

[Alexander Leidinger via freebsd-jail]

Hi.
You see the dataset name of zfs without stripping. The mount point is 
correctly stripped. I don't remember how this looks on ufs.


With jailed datasets we would need more than just some code to remove parts 
of the name.


So it's a doc bug (clarity about mount points and dataset names) and a zfs 
issue.


Bye,
Alexander.

--
Send from a mobile device, please forgive brevity and misspellings.

Am 8. Januar 2019 8:34:17 nachm. schrieb "Michael W. Lucas" 
:



Hi,

I'm experimenting with enforce_statfs for the jails book, and have hit
an inconsistency. Not sure if the bug should go to src or doc. Running
last week's -current.

According to jail(8):

When set to 1, only mount points below the jail's chroot
directory are visible.  In addition to that, the path to the
jail's chroot directory is removed from the front of their path‐
names.

Seems pretty clear that I shouldn't see anything other than

# jls -h name enforce_statfs
...
ioc-www1 1

So, as I read it, the jail's chroot directory should be stripped down
to /. But inside the jail:

root@www1:~ # mount
iocage/iocage/jails/www1/root on / (zfs, local, nfsv4acls)
devfs on /dev (devfs, local, multilabel)
fdescfs on /dev/fd (fdescfs)

I see the jail's chroot directory.

This seems to contradict the man page, unless I'm misunderstanding.

Is this a software bug? A ZFS thing? A doc bug? Or am I just an idiot?

Also, should this path be stripped when enforce_statfs is set to 1 *or
above*? Or is this strictly when set to 1? If I'm filing a bug, it
might as well be complete...

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...



--
___
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"




___
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: does anyone use these any more?

[Alexander Leidinger]

Quoting Oleg Ginzburg  (from Thu, 13 Sep 2018  
18:45:51 +0300):



With persist mode, CBSD created jail in follow scenario:

1) jail -c (create jail) in persist mode ( with empty exec.start script )
2) exec inside jail something  (zfs attach, /sbin/ifconfig ... ), what
you need to do before launching /etc/rc -> /etc/rc.d/*
3) execute normal /etc/rc sequence

in this way, /etc/rc.d/zfs can mount ZFS on 'start' stage without
execution from CBSD wrapper 'late' commands after jail start, e.g (
jexec X /sbin/zfs mount + restart all services ))

Perhaps because of a misunderstanding of this option, exec.created
hook was created in FreeBSD 12-HEAD ;-):


You could also call exec.created to be a much cleaner solution to this  
problem which also allows to do something like this with the base  
system only without the need for replacements for the jail rc scripts  
(additionally it makes it more easy for 3rd party jail management  
tools).



https://lists.freebsd.org/pipermail/freebsd-jail/2018-August/003616.html


Note, the MFC to 11 of this is on my TODO list.

Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF
___
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: IP address assignments to jails using ezjail

[Alexander Leidinger]

Quoting "James B. Byrne via freebsd-jail"   
(from Fri, 23 Dec 2016 09:33:17 -0500):



I am experimenting with jails on a bhyve vm guest running FBSD-11.0
using ezjail.  I am having a problem with network connections to the
outside from within the jail.  I have sshd configured and I can reach
the jail from the outside:

$ ssh -vv 192.168.216.196
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.216.196 [192.168.216.196] port 22.
debug1: Connection established.

But inside the jail I cannot connect out:

ssh -vv 192.168.216.22
OpenSSH_7.2p2, OpenSSL 1.0.2j-freebsd  26 Sep 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: resolving "192.168.216.22" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 192.168.216.22 [192.168.216.22] port 22.
debug1: connect to address 192.168.216.22 port 22: Operation timed out
ssh: connect to host 192.168.216.22 port 22: Operation timed out


Where is this IP located. Not on the same FreeBSD host it seems (the  
IP is not in ifconfig output below). Do a packet trace on the network  
interface of the host, what do you see in terms of packets related to  
this (ARP + IP)?



On the host system I see this:

# ifconfig
vtnet0: flags=8943
metric 0 mtu 1500
options=80028
ether 00:a0:98:fa:aa:b6
inet 216.185.71.16 netmask 0xff00 broadcast 216.185.71.255
inet 192.168.216.16 netmask 0xff00 broadcast 192.168.216.255


A /24 network config... If this is the IP of a jail I suggest to give  
it a /32 netmask.


IF this is a jail, then this may be the cause of what you see.


inet 192.168.216.196 netmask 0x broadcast 192.168.216.196
nd6 options=29
media: Ethernet 10Gbase-T 
status: active
lo0: flags=8049 metric 0 mtu 16384
options=63
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
inet 127.0.0.1 netmask 0xff00
nd6 options=21
groups: lo
lo1: flags=8049 metric 0 mtu 16384
options=63
inet 127.0.1.1 netmask 0x
nd6 options=29
groups: lo
pflog0: flags=141 metric 0 mtu 33160
groups: pflog

Inside the jail I see this:

root@hlldrupal:~ # ifconfig
vtnet0: flags=8943
metric 0 mtu 1500
options=80028
ether 00:a0:98:fa:aa:b6
inet 192.168.216.196 netmask 0x broadcast 192.168.216.196
media: Ethernet 10Gbase-T 
status: active
lo0: flags=8049 metric 0 mtu 16384
options=63
groups: lo
lo1: flags=8049 metric 0 mtu 16384
options=63
inet 127.0.1.1 netmask 0x
groups: lo
pflog0: flags=141 metric 0 mtu 33160
groups: pflog


Any ideas as to what I may have failed to do?


Can you please provide the output of "jls -v"? for all involved jails?

Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpp_Gq6IESFJ.pgp
Description: Digitale PGP-Signatur

Re: ZFS and Jail :: nullfs mount :: nothing visible from host :: solved [partial]

[Alexander Leidinger]

Quoting Miroslav Lachman <000.f...@quip.cz> (from Mon, 19 Dec 2016  
18:57:39 +0100):



Alexander Leidinger wrote on 2016/12/19 17:56:


Quoting Miroslav Lachman <000.f...@quip.cz> (from Sun, 18 Dec 2016
13:20:31 +0100):

Alexander Leidinger wrote on 2016/12/17 19:59:

Quoting SK <fbsta...@cps-intl.org> (from Fri, 16 Dec 2016 14:02:20



Correct.

You need the data in the root of the jail to boot, if you then attribute
this dataset to the jail, it will vanish until "zfs mount -a" is run (rc
script inside the jail). As it will vanish during the boot of the jail
(if added automatically), the rc script to mount all datasets can not be
found.


[...]


I think what you are trying to tell here is, unless and until that
"vanished" dataset is put to use (mounted) from inside the jail, it
will remain vanished/unusable from the host itself; however, once that
dataset is put to use, the host system should be able to "see" and
maybe even work on that dataset. Could you please confirm if I
understood you correctly?


Correct.

A sub-dataset which is not needed to boot, or a dataset not within the
subtree of the jail (and not needed to boot) can be used.


Thank you for this information! If it is somewhere in the docs it is
well hidden to me :)


I don't expect it to be in the docs. I try to come up with something for
the man page for zfs (for the "attach to jail" part), but anyone shall
feel free to beat me with this.

Anyone with an idea where in the jail man page we should add something
too (I only had a look at the zfs man page when this issue came up)?


It would be nice to have this mentioned in zfs(8) man page (that  
user in jail cannot manage jail's root dataset but can manage some  
sub-dataset not required to boot the jail)


What about this? Better wording welcome.
---snip---
Index: zfs.8
===
--- zfs.8   (Revision 298108)
+++ zfs.8   (Arbeitskopie)
@@ -450,8 +450,11 @@
 dataset can be attached to a jail by using the
 .Qq Nm Cm jail
 subcommand. You cannot attach a dataset to one jail and the children of the
-same dataset to another jails. To allow management of the dataset from within
-a jail, the
+same dataset to another jails. You can also not attach the root file system
+of the jail or any dataset which needs to be mounted before the zfs rc script
+is run inside the jail, as it would be attached unmounted until it is
+mounted from the rc script inside the jail. To allow management of the
+dataset from within a jail, the
 .Sy jailed
 property has to be set and the jail needs access to the
 .Pa /dev/zfs
---snip---

And there can be some useful example in jail(8) man page in  
EXAMPLES. There is section "Jails and File Systems" and there can be  
new section "Manage ZFS from within jail" with basic notes about  
required jail params, zfs set jailed property and example  
"hierarchy". (and warning about gotchas with jailed=0 on jail's root  
directory)


Are you willing to come up with some text-only version/draft/outline  
for this one?


Bye,
Alexander.
--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpiPSC9kMRZ8.pgp
Description: Digitale PGP-Signatur

Re: ZFS and Jail :: nullfs mount :: nothing visible from host :: solved [partial]

[Alexander Leidinger]

Quoting Miroslav Lachman <000.f...@quip.cz> (from Sun, 18 Dec 2016  
13:20:31 +0100):

Alexander Leidinger wrote on 2016/12/17 19:59:

Quoting SK <fbsta...@cps-intl.org> (from Fri, 16 Dec 2016 14:02:20 +):



If I understand you correctly, what you are suggesting is, the dataset
used by the jail itself for its root/base cannot be "worked on" from
within the jail, but if I define a different dataset (under the same
branch below the jail dataset), and attribute it to the jail, then I
can manipulate that "other" dataset. Could you please confirm if I
understood it correctly?


Correct.

You need the data in the root of the jail to boot, if you then attribute
this dataset to the jail, it will vanish until "zfs mount -a" is run (rc
script inside the jail). As it will vanish during the boot of the jail
(if added automatically), the rc script to mount all datasets can not be
found.


[...]


I think what you are trying to tell here is, unless and until that
"vanished" dataset is put to use (mounted) from inside the jail, it
will remain vanished/unusable from the host itself; however, once that
dataset is put to use, the host system should be able to "see" and
maybe even work on that dataset. Could you please confirm if I
understood you correctly?


Correct.

A sub-dataset which is not needed to boot, or a dataset not within the
subtree of the jail (and not needed to boot) can be used.


Thank you for this information! If it is somewhere in the docs it is  
well hidden to me :)


I don't expect it to be in the docs. I try to come up with something  
for the man page for zfs (for the "attach to jail" part), but anyone  
shall feel free to beat me with this.


Anyone with an idea where in the jail man page we should add something  
too (I only had a look at the zfs man page when this issue came up)?


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpYU_3k8pU6p.pgp
Description: Digitale PGP-Signatur

Re: ZFS and Jail :: nullfs mount :: nothing visible from host :: solved [partial]

[Alexander Leidinger]

Quoting SK <fbsta...@cps-intl.org> (from Fri, 16 Dec 2016 14:02:20 +):


On 16/12/2016 13:15, Alexander Leidinger wrote:


For one of the filesystems I have set "zfs allow" permissions, but  
just that a specific user in the jail can do something on those FS  
without the need to switch to root. So as long as you try to do a  
zfs create/snapshot with an user with UID 0 inside the jail, the  
"zfs allow" part doesn't come into play.


So assume space/jails/xyz.leidinger.net/ to be the dataset which  
contains the root of the jail but is not attached/attributed to the  
jail itself. space/jails/xyz.leidinger.net/data with  
mountpoint=none to be attributed ("zfs jail xyz  
space/jails/xyz.leidinger.net/data") to the jail (similar to the  
"space/something" in the ezjail config above, I have some  
iocage-managed jails were this works). In this case you should be  
able to do from inside the jail "zfs create -o mpuntpoint=/mnt  
space/jails/xyz.leidinger.net/data/test".


hmmm, I'm slightly confused at this point. Let me see if I can  
clarify that in my brain


If I understand you correctly, what you are suggesting is, the  
dataset used by the jail itself for its root/base cannot be "worked  
on" from within the jail, but if I define a different dataset (under  
the same branch below the jail dataset), and attribute it to the  
jail, then I can manipulate that "other" dataset. Could you please  
confirm if I understood it correctly?


Correct.

You need the data in the root of the jail to boot, if you then  
attribute this dataset to the jail, it will vanish until "zfs mount  
-a" is run (rc script inside the jail). As it will vanish during the  
boot of the jail (if added automatically), the rc script to mount all  
datasets can not be found.


And now to everyone, I am still confused about zfs set jailed=on.  
As I mentioned on my previous emails, as soon as I do that, the  
dataset vanishes from the host system (as I understand, that is  
expected behaviour). Then the jail fails as it is unable to mount  
/dev, /proc


From the zfs man page:
---snip---
After a dataset is attached to a jail and the jailed property is set, a
jailed file system cannot be mounted outside the jail, since the jail
administrator might have set the mount point to an unacceptable value.
---snip---

So yes, it is expected that it "vanishes", but it should be visible  
from the parent host at the place inside the jail FS subtree were  
it is mounted there (after setting the mountpoint of the dataset).


I think what you are trying to tell here is, unless and until that  
"vanished" dataset is put to use (mounted) from inside the jail, it  
will remain vanished/unusable from the host itself; however, once  
that dataset is put to use, the host system should be able to "see"  
and maybe even work on that dataset. Could you please confirm if I  
understood you correctly?


Correct.

A sub-dataset which is not needed to boot, or a dataset not within the  
subtree of the jail (and not needed to boot) can be used.


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgp_F6E8Xf12a.pgp
Description: Digitale PGP-Signatur

Re: timerfd in FreeBSD jail?

[Alexander Leidinger]

Quoting "Martin \"eto\" Misuth"  (from Tue, 6  
Sep 2016 16:07:31 +0200):



On Tue, 6 Sep 2016 13:19:13 +
Grzegorz Junka  wrote:



How would I know that this is not implemented in the linux
emulation layer rather than disabled on the host?

I would be interested in resource documenting emulated Linux syscall table
(on wiki perhaps) myself, maybe it is buried somewhere in the docs, but I
haven't found it yet.


What is implemented as a syscall:
https://svnweb.freebsd.org/base/head/sys/amd64/linux/syscalls.master?view=markup

But this doesn't include the ioctl's.

There's also (but not up-to-date):
https://wiki.freebsd.org/action/show/linux-kernel?action=show

Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpV8x2ij9YK_.pgp
Description: Digitale PGP-Signatur

Re: ezjail and UPDATING20131010

[Alexander Leidinger]

On Fri, 11 Oct 2013 15:42:11 -0500
Mark Felder f...@freebsd.org wrote:

 On Fri, Oct 11, 2013, at 14:30, Dirk Engling wrote:
  On 11.10.13 21:27, wishmaster wrote:
  
   Yeah!? But do you think updating python in each jail this is the 
   right solution? Freebsd-update in each jail?? What about when
   number of jails is 10 or about. My server is very high loaded and
   I use tunable custom kernel and world.
  
  Don't use jails then. Better go and order ten servers and use the
  amazing features of ... well, d'oh. Puppet?
  
 
 This is not the right attitude to approach this problem.

Let's take what is good from it: puppet or any other similar software.

No matter if the servers are virtualized or not, such a software is
designed to handle the package/config part of the question. With this
you can even decide which servers get an update of software X instead
of automatically updating every server and running into problems
(major updates of PHP come into my mind here).

Regarding OS updates (and I assume manual installworld updates in the
question as freebsd-update is not considered an option) I use:
---snip---
cd /usr/src
for jail in /path/to/jails/*; do
   echo $jail
   sleep 5
   mergemaster -D $jail
   make DESTDIR=$jail delete-old -DBATCH_DELETE_OLD_FILES
   make DESTDIR=$jail check-old # list old libs
fi
make DESTDIR=/path/to/basejail delete-old -DBATCH_DELETE_OLD_FILES
---snip---

Depending on the situation I use delete-old-libs instead of check-libs
(I know what gets deleted from the update of the jail-host) or issue
the delete-old-libs later when all jails don't use the libs anymore.

Bye,
Alexander.

-- 
http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
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: Exposing a hierarchy of ZFS datasets inside multiple jails

[Alexander Leidinger]

On Fri, 17 Jun 2011 14:46:59 -0400 Lars Kellogg-Stedman
l...@seas.harvard.edu wrote:

 Hello all,
 
 Hi there,
 
 I am trying to expose a hierarchy of home directories to a number of
 FreeBSD jails. The home directories are configured such that each is a
 unique ZFS dataset. The jails are used for development work and hence
 are created and destroyed on a regular basis.
 
 My first thought was simply to use nullfs to mount /home inside the
 jail, but nullfs doesn't provide any way to access subordinate
 filesystems.
 
 My second thought was to export the directories via NFS and then run
 the automounter daemon (amd) inside each jail. This would have Just
 Worked...if it were possible to perform NFS mounts inside a jail. But
 it's not.

See the second part of the patch at
http://www.leidinger.net/FreeBSD/current-patches/sys:nfsclient.diff
for how to allow NFS mounts in a jail.

Bye,
Alexander.

-- 
http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
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: Fwd: X11 in a jail (was: Re: NFS mount inside jail fails)

[Alexander Leidinger]

Quoting Alexander Leidinger alexan...@leidinger.net (from Fri, 27  
May 2011 09:43:08 +0200):


Quoting Doug Ambrisko ambri...@ambrisko.com (from Thu, 26 May 2011  
10:36:24 -0700 (PDT)):



Alexander Leidinger writes:



| Just to make sure we talk about the same things:
| Did you configure the X server to use 3D (dri and glx in the modules
| section, dri section in the X11 config, dri device visible in devfs)?
| xdriinfo shows some valid hardware acceleration?



a part of Xorg.log
 (WW) intel(0): DRI2 requires UXA
 drmOpenDevice: node name is /dev/dri/card0
 drmOpenDevice: open result is 10, (OK)
 drmOpenDevice: node name is /dev/dri/card0
 drmOpenDevice: open result is 10, (OK)
 drmOpenByBusid: Searching for BusID pci::00:02.0
 drmOpenDevice: node name is /dev/dri/card0
 drmOpenDevice: open result is 10, (OK)
 drmOpenByBusid: drmOpenMinor returns 10
 drmOpenByBusid: drmGetBusid reports pci::00:02.0
 (II) [drm] DRM interface version 1.2
 (II) [drm] DRM open master succeeded.



 (II) intel(0): [dri] visual configs initialized


That's the first time I see 3D enabled in a jail with my patch. I  
definitively need to get some time to try it with my radeon again.


Any opinions here on jail@ about committing the kernel part (not the  
rc.d part) of the patch?

  http://www.leidinger.net/FreeBSD/current-patches/0_jail.diff


FYI: I got confirmation from someone off-list that 3D also works (at  
least is enabled according to the X11 log) on 8-stable (an adaption of  
it, off course) with a GeForce 8400GS (I'm not sure if it is the  
driver from NVidia or the open source one, but I have the impression  
it is the closed-source one):

---snip---
(II) Loading extension NV-GLX
(II) May 12 18:18:44 NVIDIA(0): Initialized OpenGL Acceleration
---snip---

Bye,
Alexander.

--
Where's th' DAFFY DUCK EXHIBIT??

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
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: Thoughts on jail.config

[Alexander Leidinger]

Quoting James O'Gorman ja...@netinertia.co.uk (from Mon, 28 Jun 2010  
23:40:21 +0100):



On 28 Jun 2010, at 16:38, Jamie Gritton wrote:


On 06/28/10 08:41, Rodrigo Mosconi wrote:


An idea: if it works like a jaild? A daemon management the start-up,
shutdown, console redirection?  All the admins task could be done by a
jailctl?


I don't know what work a daemon would have to do. I only see it running
tasks on startup, and then waiting until something tells it on shutdown
to wake up and stop the jails. That something would have to be that
jailctl you mention. If there's a jail program running anyway, might as
well keep all functionality in that one program.


Perhaps it's worth looking at Solaris Zones here, as that runs a  
daemon in both the global zone and each container. I can't recall  
exactly what it does off-hand as I don't have a Solaris box to hand  
but it's probably similar to what you're talking about. I'm pretty  
sure zoneadm talks to zoneadmd to start/stop/configure each zone in  
the kernel.


Yes, but it also takes care about the zone console device  
(http://docs.sun.com/app/docs/doc/817-1592/z.inst.ov-12?l=ena=view).  
This (and maybe some resource control stuff) is the only thing I see  
which may make sense to be handled by a daemon, everything else could  
be handled by zoneadm directly. I also see a security benefit of the  
daemon if you give the right to manage zones to an user/role != root.  
Both is not available in FreeBSD.


There is also the zsched running per zone. This process is explained  
at http://docs.sun.com/app/docs/doc/817-1592/z.inst.ov-13?a=view


Bye,
Alexander.


--
Never have so many understood so little about so much.
-- James Burke

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
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: Strange things happening with jails?? Not starting up on boot or services not running inside!

[Alexander Leidinger]

Quoting Andrew Hotlab andrew.hot...@hotmail.com (from Thu, 3 Jun  
2010 22:04:44 +):


I've never had to make Squid listening on port 80, but referring its  
startup script in /usr/local/etc/rc.d/:


# squid_user:   The user id that should be used to run the Squid master
#   process. Default: squid.
#   Note that you probably need to define squid_user=root if
#   you want to run Squid in reverse proxy setups or if you want
#   Squid to listen on a privileged port  1024.

So you only need to write the following line in /etc/rc.conf to have  
Squid listening on this privileged port:

squid_user=root


An alternative is to change the sysctl  
net.inet.ip.portrange.reservedhigh. By lowering it, other users than  
root are allowed to bind to ports 1023 (the system prevents non-root  
binds to the port X in the range reservedlow = X = reservedhigh).


Bye,
Alexander.

--
The District of Columbia has a law forbidding you to exert pressure on
a balloon and thereby cause a whistling sound on the streets.

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
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: starting jails in the background dependencies

[Alexander Leidinger]

On Tue, 5 Jan 2010 11:24:47 +0100 Alexander Leidinger
alexan...@leidinger.net wrote:

 On Mon, 07 Dec 2009 08:03:53 +0100 Alexander Leidinger
 alexan...@leidinger.net wrote:
 
  Hi,
  
  now that jails are started in the background (which is good, to
 
 I just realized yesterday that it also stops in parallel (in the
 background). This is bad. It may be the case that a jail is not fully
 stopped via the rc scripts when the OS decides to kill the remaining
 processes during a shutdown.
 
 My first reaction is to only allow to start in the background, but
 everything else needs to be serialized.

I committed now what was discussed in this thread:
 - no start in the background by default
 - only start is allowed to happen in background when
   jail_parallel_start is set to yes in rc.conf
 - stdin is redirected from /dev/null

If someone is not happy about the name of the rc.conf variable: feel
free to change it, I do not care about the name.

Bye,
Alexander.
___
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: linux-only jail possible?

[Alexander Leidinger]

On Wed, 3 Mar 2010 19:06:36 +0100 Roman Divacky rdiva...@freebsd.org
wrote:

 On Wed, Mar 03, 2010 at 11:59:49AM -0500, John Nielsen wrote:
  On Wednesday 03 March 2010 03:00:50 Roman Divacky wrote:
   I succesfully ran chroot of linux environment on freebsd back in
   2007/2008. I firmly believe jail should work fine too
  
  Good to know, thanks! Would you mind sharing some more details?
  (Off-list is fine if you prefer.) Was it a more or less complete
  environment? What distro / version of Linux?
 
 I downloaded gentoo 2007 untarred it into /compat/linux and
 chroot /compat/linux /bin/bash
 
 it just worked - nothing special was necessary
 
 dont remember much details but I had no problems with that setup

It does not need to be in this directory off course. You can install
the gentoo-dist ports (not the gentoo-baase port). After that you can
copy all the files to the place where you want to have the jail.

Now you just need to configure a jail. It does not matter much if you
use the jail stuff in the base system or a framework like ezjail or
similar, as long as you configure an appropriate startup script in the
linux-jail. The linux-startup part you need to do yourself, I do not
think the default linux startup stuff is approrpiate. I suggest to
start at least a sshd before you start the software you want to
use. This way you can login into the linux-jail and investigate issues
like it is a real system.

I suggest to monitor the kernel messages on the FreeBSD host. There may
be linux-syscalls which are not implemented (e.g. epoll stuff). There
is currently no effort to implement those. There may be partial
implementations for some sysctls (Roman has something somewhere), but
nothing is in FreeBSD and no efforts are on the way to bring them in.
If your software needs something like this, you either need to
implement them yourself, switch the software to not use this (maybe
by changing the linux emulation to 2.4 instead of 2.6), or to forget
about using FreeBSD for this. emulation@ is a good address to ask
questions regarding the status of things,
http://wiki.freebsd.org/linux-kernel has some infos too.

Bye,
Alexander.
___
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: Importing jails from 7.0, 7.2 to 8.0.

[Alexander Leidinger]

On Mon, 8 Feb 2010 11:29:41 -0800 Jose Amengual M
jose.ameng...@gmail.com wrote:

 My question is :
 
 Do I need to reinstall portupgrade and reinstall all ports ?
 
 Did I do the proper export and import process ?
 
 The jail where running on 7.0 and the basejail dir was from 7.0, now
 is from 8.0 and I understand that I have to do some reinstall or
 upgrade process but I think that I skipped some steps :).

The problem is that you didn't copy the basejail from 7.0. If you would
have copied it, the jails would be running just fine.

What you see now is that programs in the jails reference a library
which is in 7.0, but not in 8.0 (more detailed: the lib itself is
there, but with a different major version, and a different major
version means that there are incompatible differences).

A smooth transition would have been to use the 7.0 basejail, update it
with 8.0 (ezjail update + foreach jail a mergemaster -D /path/to/jailX),
rebuild all the ports in the jails, and then to run cd /usr/src/ ; make
delete-old delete-old-libs DESTDIR=/path/to/basejail. After that you
need to check if all programs in the jails still work (you can install
the libchk port and let it search for missing libs and rebuild ports
which depend upon missing libs).

Bye,
Alexander.
___
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: starting jails in the background dependencies

[Alexander Leidinger]

Quoting Remko Lodder re...@freebsd.org (from Tue, 5 Jan 2010  
11:35:48 +0100):




On Tue, January 5, 2010 11:24 am, Alexander Leidinger wrote:

On Mon, 07 Dec 2009 08:03:53 +0100 Alexander Leidinger
alexan...@leidinger.net wrote:


Hi,

now that jails are started in the background (which is good, to


I just realized yesterday that it also stops in parallel (in the
background). This is bad. It may be the case that a jail is not fully
stopped via the rc scripts when the OS decides to kill the remaining
processes during a shutdown.

My first reaction is to only allow to start in the background, but
everything else needs to be serialized.

Any objections or better ideas out there?



I think the best way at this moment is to revert the change ( I can do
that , or someone else, I dont mind ) and think of a better concept. Simon
also mentioned that he didn't like the current way of doing things, so I
kept it in, for possible suggestions. Reverting the change would mean that
the old behaviour at least works and is with what people are used to. We
can then further improve it where needed.


What about the following? Just have a look at the principle, I haven't  
tested it yet. What it does is:

 - revert back to serial startup by default
 - allow to only start in the background (jail_parallel_start=YES)
 - take input from /dev/null: in case a start script inside the
   jail wants to read from stdin (it shouldn't), it will not
   switch the process into STOP state (but should generate some
   message in the application log)

Copypaste, so maybe messed up tabs:
---snip---
Index: share/man/man5/rc.conf.5
===
--- share/man/man5/rc.conf.5(Revision 202277)
+++ share/man/man5/rc.conf.5(Arbeitskopie)
@@ -24,7 +24,7 @@
 .\
 .\ $FreeBSD$
 .\
-.Dd November 11, 2009
+.Dd January 14, 2010
 .Dt RC.CONF 5
 .Os
 .Sh NAME
@@ -3472,6 +3472,11 @@
 If set to
 .Dq Li NO ,
 any configured jails will not be started.
+.It jail_parallel_start
+.Pq Vt bool
+If set to
+.Dq Li YES
+all configured jails will be started in the background (= in parallel).
 .It Va jail_list
 .Pq Vt str
 A space separated list of names for jails.
Index: etc/rc.d/jail
===
--- etc/rc.d/jail   (Revision 202277)
+++ etc/rc.d/jail   (Arbeitskopie)
@@ -636,7 +636,8 @@
done

eval ${_setfib} jail ${_flags} -i ${_rootdir} ${_hostname} \
-   \${_addrl}\ ${_exec_start}  ${_tmp_jail} 21
+   \${_addrl}\ ${_exec_start}  ${_tmp_jail} 21 \
+   /dev/null

if [ $? -eq 0 ] ; then
_jail_id=$(head -1 ${_tmp_jail})
@@ -728,4 +729,19 @@
 if [ -n $* ]; then
jail_list=$*
 fi
-run_rc_command ${cmd} 
+
+# Only allow the parallel start of jails, other commands are not
+# safe to execute in parallel.
+case ${cmd} in
+*start)
+   ;;
+*)
+   jail_parallel_start=NO
+esac
+
+if checkyesno jail_parallel_start; then
+   run_rc_command ${cmd} 
+else
+   run_rc_command ${cmd}
+fi
+
Index: etc/defaults/rc.conf
===
--- etc/defaults/rc.conf(Revision 202277)
+++ etc/defaults/rc.conf(Arbeitskopie)
@@ -630,6 +630,7 @@
 ### Jail Configuration ###
 ##
 jail_enable=NO   # Set to NO to disable starting of any jails
+jail_parallel_start=NO   # Start jails in the background
 jail_list=   # Space separated list of names of jails
 jail_set_hostname_allow=YES # Allow root user in a jail to change  
its hostname

 jail_socket_unixiproute_only=YES # Route only TCP/IP within a jail
---snip---

Bye,
Alexander.

--
For certain people, after fifty, litigation takes the place of sex.
-- Gore Vidal

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
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: starting jails in the background dependencies

[Alexander Leidinger]

Quoting Miroslav Lachman 000.f...@quip.cz (from Tue, 05 Jan 2010  
11:45:34 +0100):



Alexander Leidinger wrote:

On Mon, 07 Dec 2009 08:03:53 +0100 Alexander Leidinger
alexan...@leidinger.net  wrote:


Hi,

now that jails are started in the background (which is good, to


I just realized yesterday that it also stops in parallel (in the
background). This is bad. It may be the case that a jail is not fully
stopped via the rc scripts when the OS decides to kill the remaining
processes during a shutdown.

My first reaction is to only allow to start in the background, but
everything else needs to be serialized.

Any objections or better ideas out there?


Maybe stopping can be done in parallel, but rc script should wait  
(in loop) until all jails are stopped or some configurable timeout  
(for example 60 seconds).


Feel free to come up with a proof of concept... but the timeout on  
stop should be forever IMO. If you have a busy software which needs  
to be shutdown correctly for data safety or consistency reasons, I do  
not want that a reboot or shutdown prevents the correct shutdown.


Bye,
Alexander.

--
Beware of Programmers who carry screwdrivers.
-- Leonard Brandwein

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
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

starting jails in the background dependencies

[Alexander Leidinger]

Hi,

now that jails are started in the background (which is good, to  
prevent that a broken jail causes a good jail not to start), I have to  
problem how to express dependencies.


Scenario:
 - several jails on the same machine (via ezjail)
 - one jail depends on the services of another jail, e.g.
   - jail0 with a DNS server
   - jailA with mysql (requires that jail0 is up)
   - jailB needs access to the mysql of the jailA (and DNS of
 jail0)

Currently all jails are started in parallel. This may lead to a  
situation where something in jailB wants to access jailA before mysql  
is available.


In my case I have the special condition that I need to run a script  
(rc.d) on the jail-host, after two specific jails are started:

 - I have a good PROVIDE line in /usr/local/etc/ezjail/jailA
   (and jail0)
 - I have a corresponding REQUIRE line in
   /usr/local/etc/ezjail/jailB (and jailA for jail0)
 - rc.d/ezjail is called before my script (it hardlinks the
   mysql socket into jailB)
 - the jails are started in parallel - rc.d/ezjail finishes
   before mysql is started
 - my link-script starts before mysql is up - no DB connection
   possible from jailB (configured to use the unix domain socket)

In my case it would be OK to block the start of everything if one jail  
starts, so the easy solution would be to introduce a  
jail_background_start variable (default: yes).


Does someone have a better idea how to solve this? If not, any  
objections against the jail_background_start solution?


Bye,
Alexander.

--
Sanity and insanity overlap a fine grey line.

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
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: xorg in jail

[Alexander Leidinger]

On Sat, 10 Oct 2009 10:14:26 +0200 Kevin Smith ker...@gmail.com wrote:

 Does this patch fix vnc server start error also ?

I don't know. The patch allows access to /dev/io. Normally this is not
possible, even if /dev/io is visible in the jail, as the kernel
disallows all access to it from a jail.

 When I try to run tightvncserver in a jail it says:
 
 A VNC server is already running as :0

I wouldn't expect that a VNC server needs access to /dev/io, so I
would be surprised if this would help.

 even if there is no vnc server running.

You could start it via ktrace -i tightvncserver and when it abortet
you can have a look with kdump|less what it tries to do.

Bye,
Alexander.

 Thank you,
 regards
 
 On Oct 9, 2009, at 10:45 AM, Alexander Leidinger wrote:
 
  Quoting hulibyaka hulibyaka huliby...@gmail.com (from Thu, 8 Oct  
  2009 22:01:23 +0400):
 
  What the difference for restriction on /dev/io between chroot and
  jail? How  can i get all needed by xinit privileges on /dev/io
  within jail ?
 
  There are additional access restrictions in the kernel when run in
  a jail. You need
   http://www.leidinger.net/FreeBSD/current-patches/jail.diff
  and you need to rebuild the kernel and the world.
 
  After that you need to add  
  jail_JAILID_startparams=allow.dev_io_access for your jail startup.
 
  Bye,
  Alexander.
 
  -- 
  Pie are not square.  Pie are round.  Cornbread are square.
 
  http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID =  
  B0063FE7
  http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID =  
  72077137
  ___
  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
 
 --
 Kevin
 

___
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: xorg in jail

[Alexander Leidinger]

Quoting hulibyaka hulibyaka huliby...@gmail.com (from Thu, 8 Oct  
2009 22:01:23 +0400):



What the difference for restriction on /dev/io between chroot and
jail? How  can i get all needed by xinit privileges on /dev/io within
jail ?


There are additional access restrictions in the kernel when run in a  
jail. You need

  http://www.leidinger.net/FreeBSD/current-patches/jail.diff
and you need to rebuild the kernel and the world.

After that you need to add  
jail_JAILID_startparams=allow.dev_io_access for your jail startup.


Bye,
Alexander.

--
Pie are not square.  Pie are round.  Cornbread are square.

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
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: Best practice to update jails

[Alexander Leidinger]

On Thu, 20 Aug 2009 11:50:49 -0700 Jose Amengual
jose.ameng...@gmail.com wrote:

 The server is now 7.0 and was wondering what is the best practice to  
 maintain security patches and kernel updates and I came out with the  
 following idea :
 
 1.- freebsd-update fetch install ( host system)
 2.- rebuild kernel ( I have a custom kernel )
 3.- ezjail-update -b ( update basejail for all jails )
 4.- run in cron portaudit on the jails for thirty party security
 updates 5.- run portupgrade in case of a security update or for apps
 upgrade on the jails.
 
 I red in some forums that if you run freebsd-update you will need to  
 do a portuprade -fa to reinstall all the thirty party apps because  
 freebsd-update could upgrade or remove  some libraries linked to
 that programs, is this true ?, will be better to run a cvsup and
 instead ?

Not if you stay with the same major version of FreeBSD. If you update
from 7 to 8, this may be possible (I don't know, I don't use
freebsd-update, as I either run patched systems, or at least compile
my own kernels), but if you update from 7.x to 7.y, then this would be
an ABI change, which is very very very very much a no no in a
stable-branch (only an important security fix would be allowed to do
something like this, and only if nobody finds another way to do such
a fix without changing the ABI).

So if you stay on the same major version you can use your procedure,
but read the release notes before, such a big impact change is
announced on a stable branch. It may be the case that we had something
like this once, but I do not remember which major version was affected.

Bye,
Alexander.


___
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: Multicast in jail?

[Alexander Leidinger]

Quoting Bill Marquette bill.marque...@ucsecurity.com (from Mon, 6  
Jul 2009 20:14:02 -0500 (CDT)):


I'm trying to run Avahi in a jail, much the same as Alexander  
Leidinger in this email from late last year  
http://www.mail-archive.com/freebsd-jail@freebsd.org/msg00587.html.   
I couldn't find any replies to that thread and it seems that I'm  
running into the same issues - the service announcements make it on  
the wire and the other devices in the network see them.


So far I have nothing working.

I assume that the mcast traffic is not arriving at all IPs. wild  
guessEither because on overly restrictive jail check, and/or just  
because there's no code which is distributing the traffic to all  
IPs./wild guess


It seems kern_jail.c is a place to check if there's some code which  
handles this. Maybe prison_check_ip[46] if mcast is on top of this, or  
something new to write if mcast is a different AF. Again, this is a  
wild guess, I don't have enough understanding of the network code in  
the kernel to even make educated guesses about the real reason.


Bye,
Alexander.

--
Ask not for whom the Bell tolls, and you
will pay only the station-to-station rate.
-- Howard Kandel

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
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: Multicast in jail?

[Alexander Leidinger]

Quoting Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net (from Tue, 7  
Jul 2009 11:08:46 + (UTC)):



Alternatively I wouldn't wonder if enabling raw sockets would give


Didn't work for me.


what you want or you'll wait for virtualization to be ready.


As _I_ don't need it on -stable: it's what I'm waiting for.

Bye,
Alexander.

--
The greatest of faults is to be conscious of none.

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
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: Switching /etc/rc.d/jail to new syntax (+ new features)

[Alexander Leidinger]

On Sat, 27 Jun 2009 10:47:47 + (UTC) Bjoern A. Zeeb
bzeeb-li...@lists.zabbadoz.net wrote:


 On Sat, 27 Jun 2009, Alexander Leidinger wrote:
 
  at http://www.leidinger.net/FreeBSD/current-patches/jail.diff I
  have a patch to switch the jail rc script to the new jail
  (8-current) syntax. This includes new config options for a jail
  (see etc/defaults/rc.conf after patching). The patch also contains
  my X-in-a-jail stuff (feel free to ignore this part, it's disabled
  by default).
 
  If you do not make any config change, you will be able to see all
  mounted filesystems of the entire machine. To get back to the
  previous behavior, you have to add a config option:
   jail_XXX_startparams=enforce_statfs=2
 
  This config option can also take other jail parameters like
  allow.sysvipc and other ones described in the jail man-page
  (additional parameters need to be space separated).
 
  Feedback welcome.
 
 1) it break various things that will no longer work

As mentioned, it breaks the statfs part. If there's anything else, be
more specific please.

 2) it's not a poper solution

The proper solution for the statfs part would be, that jail(8) defaults
to =2 if nothing is specified. Alternatively I can get convinced that
we should do a default for it in defaults/rc.conf if nothing is specied
for startparams for a particular jail (like we have for some other
things), but this would not be as good as if jail(8) would handle it
itself.

If you do not talk about the statfs part but in a more generic way,
what would be a proper solution in your eyes?

Bye,
Alexander.
___
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: HEADS UP: r185435 multi-IPv4/v6/no-IP jails in HEAD

[Alexander Leidinger]

Quoting Bjoern A. Zeeb [EMAIL PROTECTED] (from Mon, 1  
Dec 2008 09:41:46 + (UTC)):



Hi,

as you may have already noticed multi-IPv4/v6/no-IP jails have hit
HEAD. See commit message attached.


Will this introduce changes how multicast is handled in jails, or is  
it the same behavior as before (whatever the previous behavior was).



Additionally you can give a jail a name now using the -n option:
  jail -n bz's private noip jail / noip.example.net  /bin/sh
You may not want to use special characters or whitespace but it is
just a string, so you can. There are no restrictions and even 10 jails
could have the same name. The jail (inside) cannot change the name.
It's set upon jail creation and unchangeable from then on.


Is this private name visible inside the jail (I don't need this  
feature, so I don't care, but people should know so that they don't  
put offensive stuff there in case it is visible inside)?


Bye,
Alexander.

--
Since we cannot hope for order, let us withdraw with style from the chaos.
-- Tom Stoppard

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-jail@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Compilation question 64bit, 32 bit

[Alexander Leidinger]

Quoting Miroslav Lachman [EMAIL PROTECTED] (from Fri, 17 Oct 2008  
11:48:03 +0200):



Alexander Leidinger wrote:
Quoting Jose Amengual [EMAIL PROTECTED] (from Thu, 16 Oct  
2008  08:43:15 -0300):



Hi Guys.

The other day I install a server with jails with FreeBSD 7 32 bit  
in  a 64 bit capable processor.


After I install I start wondering some things that I point out here :

Any benefit to install 64 bit vs 32 bit with the purpose of use jails ?



It depends. If you want to use more than 4G: yes.

Can I install a 32 bit FreeBSD and create 64 bit jails ? ( using   
ezjail or downloading the full 64 bit source to create the jail ).



No.

Can I install 32 bit FreeBSD and then made a make world and change  
 it to 64 bit ? ( is recommended ?)



IIRC this depends upon your FreeBSD version. I think in CURRENT   
there's code which supports that now. No guarantees.



Can I install a FreeBSD 64 bit and create 32 bit jails ?



Sort of. You can install a 32bit world into the jail and make sure   
32bit support is activated in the kernel. The 32bit programs will  
then  run just fine in the jail (but 64bit ones should run fine  
too). It's  the same way as you can run linux programs in a jail.


Do you mean installing whole 32bit world instead of 64bit, for  
example from  
ftp.freebsd.cz:/pub/FreeBSD/releases/i386/7.0-RELEASE/base/ or just  
/lib32 /usr/lib32 libraries?


I haven't tested it myself. I know that it is possible. It may need  
some twiddling. I haven't carefully looked at the kernel code, but as  
it uses the same infrastructure as the linuxulator (see  
compat/ia32/ia32_sysvec.c), it should be able to run with a plain i386  
world (maybe you have to make a link /libexec/ld-elf32.so.1 -  
/libexec/ld-elf.so.1 as the compat32 stuff is trying to access this...  
or maybe even moving ld-elf.so.1 to a different name and linking to  
the new name, in case this may cause some kind of loop in the kernel).


Will it be possible in this (32bit) jail to install ports marked as  
arch i386 only, or some voodoo is needed to trick the ports system?


As the compiler is responsible to create the XXbit stuff, and you are  
using the 32bit compiler, it should be possible. Investigate the stuff  
which is used to change the uname output on the ports build cluster.  
This will be needed. Not all ports may work, in this case either fix  
the port, or use a package. Some ports will never be able to work (use  
of features which are not available in compat32).


What do you mean by 32bit support in kernel? Is it just options
COMPAT_IA32 as is in amd64 GENERIC or anything else?


COMPAT_IA32


I am interested in running 32bit ports on amd64 bit machine.


If you mean 64bit jail instead of machine: should be possible. If not:  
mixing without restrictions is not possible. It's an all or nothing  
approach for the userland.


Bye,
Alexander.

--
If society fits you comfortably enough, you call it freedom.
-- Robert Frost

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-jail@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: samba inside jails [was: jail/broadcast IP [was: ...]]

[Alexander Leidinger]

Quoting Bjoern A. Zeeb [EMAIL PROTECTED] (from Fri, 3  
Oct 2008 08:21:53 + (UTC)):



3) In samba it used to be the
interfaces =
   config option that you would set to the (primary) IP of your jail.

With the above you should be able to address the samba server inside
the jail and exchange files and all that. At least I was able to back
then. Things may have changed.


I have samba running in a jail (8-current from a month or two ago, no  
multi-IP patch). No problems here.



Depending on your setup browsing via good old braodcast stuff might
not work but in any modern setup that should no longer be needed imho.


I use it with network drives, so I'm not sure about broadcasts...

Bye,
Alexander.

--
Truth never comes into the world but like a bastard, to the ignominy
of him that brought her birth.
-- Milton

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-jail@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Migration of Jail from one host to another?

[Alexander Leidinger]

Quoting Scott Lambert [EMAIL PROTECTED] (from Wed, 2 Jul 2008  
15:22:35 -0500):



I'm probably doing this completely wrong.  I setup a couple of jails
using simple image files because I thought that would make migration
to another server more straightforward.  I am now trying to migrate my
first jail.


A little bit late, but I moved 2 ezjails today (on 8-current). It was  
setup inside a ZFS, not in an image. It worked without problems (I  
transferred the ZFS data (zfs send | zfs receive), the fstab file, and  
the ezjail config file).



 /usr/local/etc/rc.d/ezjail.sh start
 ezjailConfiguring jails:.
Starting jails: testnetmount: /home/ezjails/migrate.jail.device :  
Operation not permitted


You have a problem here. You may want to look into ezjail what the  
testnetmount is doing. I assume there's some problem with creating the  
md device.



df: /home/ezjails/migrate.jail/dev: No such file or directory
mount: /home/ezjails/migrate.jail/dev: No such file or directory


I think this and the rest are followup errors of the failed mount of  
the disk image.


Bye,
Alexander.

--
You may get an opportunity for advancement today.  Watch it!

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-jail@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: is nfs mount inside jail possible?

[Alexander Leidinger]

Quoting Robert Watson [EMAIL PROTECTED] (from Wed, 25 Jun 2008  
17:53:36 +0100 (BST)):


I don't know of any specific vulnerabilities that will open up, and  
I don't have time to read the source code to find them now, but I do  
promise you that if you allow arbitrary mounting of file systems in  
jail, you will likely run into quite a few, simply because mounting  
of file systems is a sensitive operation, modifies the file system


I agree, but I put the focus on arbitrary. What I specially did not  
include in the list was ufs, procfs, fdescfs and some more.


UFS can cause a kernel panic if used with a bad FS image. For procfs  
we even recommend to not mount it in a normal system, and for others I  
don't know if they are robust enough.


For nullfs all depends if it can break out of the jail or not. If it  
can not, I don't see why we should not allow to mount it in a jail.  
Based upon what I've read in the source, it's even easy to test. As it  
gets path names the kernel resolves itself, the test would be to  
modify mount_nullfs to not do the realpath, and test by adding some  
../ into the path (ok, this is a simplified description, there are  
several cases which have to be tested, but it is not rocked science).


For other FS it depends what they are/do and how robust they are.  
Wasn't there a FS-fuzzing paper a while ago which tested several  
FreeBSD FS for robustness? Very interesting would be the robustness  
for cd9660, msdosfs and udf. Those are candidates which would be  
interesting to use in a jail.


So, per my comments, I would recommend extreme caution because the  
implications are very tricky to reason about, requiring careful  
auditing of source code to ensure that expected protections will  
continue to be enforced. Caveat emptor.  Beware the dog.  Enter at  
your own risk.  There be dragons. Run away!


I agree with everything except the Run away! :) This is CS, the  
outcome should be deterministic... :)


Bye,
Alexander.

--
Man who sleep in beer keg wake up stickey.

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-jail@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: is nfs mount inside jail possible?

[Alexander Leidinger]

Quoting Robert Watson [EMAIL PROTECTED] (from Wed, 25 Jun 2008  
16:57:17 +0100 (BST)):



On Wed, 25 Jun 2008, Alexander Leidinger wrote:

Oh: I haven't checked if this actually works. I don't know if all  
places DTRT then. Normally it should work, but you better test if  
it really puts the FS in the place where you want it, that you can  
mount/umount it, that mount -v shows the expected output on the  
host and in the jail, and so on.


Similar things can be done for  
src/sys/fs/{cd9660|msdosfs|ntfs|nullfs|smbfs|udf|unionfs}. Those  
are the FS's which _should_ be safe, either because they work with  
untrusted data anyway, or because it's a loopback mount. But again,  
I haven't tested any of them (I have them patched locally, but even  
the initial testing is on my TODO list with a low priority).


Safe in the sense that they might, or might not, immediately panic.   
Not safe in the sense that the resulting system would necessarily  
have the expected or desired security properties.  It wouldn't  
surprise me if, just for example, allowing user mounting of nullfs  
from within jail allowed the user to escape from the jail and access  
files outside the jail in the host system.


I just had a look at the man page of nmount (that's what is used to  
mount nullfs, and some other FS's). nmount gets the pathname  
(realpath). realpath prints the path relative to the jail root, not  
the real name in the jail-host. If nmount is not jail aware, then we  
have a meltdown. nmount is using NDINIT/namei. If I read namei/NDINIT  
correctly, it picks the correct path in a jail (else name lookups in a  
jail wouldn't work, right?). Any filesystem which gets a source path  
also needs to use namei (AFAIK, please correct me if I'm wrong), so  
this side of the mounting has the same properties.


For FS's which don't use nmount but the old mount stuff, I don't know.

Establishing that this is not the case is fairly non-trivial and has  
to be done very carefully.  I would recommend extreme caution.


At least for nmount based things this would implicitly mean we have a  
_very_ big problem with jails (if my above analysis of the code is  
correct) in other places, as the mountpoint is resolved via namei in  
the kernel.


Bye,
Alexander.

--
Personnel recruiting is a triumph of hope over
experience.

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-jail@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Signal 11 messages showing in all jails?

[Alexander Leidinger]

Quoting Scott Lambert [EMAIL PROTECTED] (from Mon, 19 May 2008  
00:17:07 -0500):



Is this supposed to happen?  FreeBSD 6.2

order.cgi is only installed in one jail on this system, but I see
this report in all the jail on that system.  The below lines are from
the daily security run output for one of the other jails.

I just want to make sure this is operating as expected rather than a
bug.


It's not only the signal 11 messages, it's all kernel messages.  
There's no jail filter for the kernel messages, so this is expected  
behavior (this doesn't mean this behavior is the right one).


Bye,
Alexander.

--
Most people need some of their problems
to help take their mind off some of the others.

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-jail@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Signal 11 messages showing in all jails?

[Alexander Leidinger]

Quoting Andrew Snow [EMAIL PROTECTED] (from Mon, 19 May 2008  
21:08:38 +1000):




Sorry for previous message, it wasn't devfs rules at all that solved  
this problem.


The rules you posted are part of some kind of workaround. The rules  
didn't include the syslog pipe for kernel messages (depends upon  
your version of FreeBSD), so there should be no messages from the  
kernel (like sig 11) in the syslog anymore with this.



Instead you should set this in /etc/sysctl.conf:

  security.bsd.unprivileged_read_msgbuf=0


This also has implication for the jail-host. You need to be root to  
read the dmesg.


All this is just a workaround, but not really a solution to the  
problem. Ideally each jail gets messages from the kernel which  
_belong_ into this jail (e.g. sig 11, if a process from _this_ jail  
dies in this way).


Bye,
Alexander.

--
Pure drivel tends to drive ordinary
drivel off the TV screen.

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-jail@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: freebsd-update on jails

[Alexander Leidinger]

Quoting Jeffrey Smith [EMAIL PROTECTED] (from Sun, 20 Apr  
2008 15:49:39 -0400):



  I previously posted a howto to use zfs to manage jails.  The first
update through freebsd-update has been released.  Testing this I get

[snip]

But I still get that same error.  Does anyone have any idea what would
keep this from working?  If there is a way to update the host and all
subsequent jails vi the host that would be great, as i would prefer not
to allow chflags from within the jails.


If you have your jail on ZFS I suggest you check that the original  
file has flags at all. I doubt it (as ZFS doesn't handle flags (yet?)).


Bye,
Alexander.

--
Home on the Range was originally written in beef-flat.

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-jail@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: pam _start: system error

[Alexander Leidinger]

Quoting Kalnz [EMAIL PROTECTED] (from Mon, 27 Aug 2007 12:54:19 +0300):


Hi!

After installing (in the jail) mysql-server-5.0.45 from ports,
I can`t get up and running my mysql server.
I have to point out that this problem is only inside the jail.
All I have is:
1) clean mysql-server install
2) default my.cnf (small systems)
3) mysql_enable=YES

After this server should run, but it didn`t, so I get this:

# /usr/local/etc/rc.d/mysql-server start
Starting mysql.
su: pam_start: system error
#

In the logs there is:
su: in openpam_load_module(): no pam_unix.so found
su: pam_start: system error

In fact pam_unix.so file is present in /usr/lib directory.
I`m sure this is because of jail, but I can`t figure out what could be
the problem.


How do you startup the jail, how have you populated the basesystem in  
the jail initially? What's the size of pam_unix.so, what does file  
/usr/lib/pam_unix.so print?


Bye,
Alexander.

--
Old age is too high a price to pay for maturity.

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-jail@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Jailed X applications

[Alexander Leidinger]

Quoting mal content [EMAIL PROTECTED] (from Fri, 17 Aug  
2007 17:00:00 +0100):



On 17/08/07, Alexander Leidinger [EMAIL PROTECTED] wrote:

Quoting mal content [EMAIL PROTECTED] (from Fri, 17 Aug



 Has anyone here ever successfully set up a jail for X apps, connecting
 to an external X server? I'm trying an experimental sandbox setup here.

I have my X server itself in a jail (needs a kernel patch and some
devfs rules), and in the past connected to a jail and started a X11
programm there... IIRC.


I think you may misunderstand me. In this setup, my X
server is actually running on my host, outside of any
jail. I intend for programs running inside the jail
to connect to the X server with TCP/IP:


I haven't misunderstood you. I just explained that I even have a more  
restrictive configuration running.



  ssh -N -L 6000:hostip:6000 [EMAIL PROTECTED] 
  xterm -display 127.0.0.1:6000


ssh itself opens an X11 tunnel for you if you use -X (xauth has to be  
present on ... both(?) hosts), it also sets the DISPLAY variable. So  
maybe

   ssh -f -X [EMAIL PROTECTED] xterm 
would be a better idea.

You command maybe misses the -g for ssh, or alternatively use -R  
instead of -L. -T disables the allocation of a pseudoi-tty, but this  
should not be necessary, try all the other possibilities first (you  
can use -v to get some more information what ssh does).



The intention is to also place some sort of custom X
proxy before the actual server, to do inspection on the
protocol before it is passed to the real server. This
is for later, however.


Should be possible even with the built-in X-tunnel (just give the  
value of the ssh DISPLAY to the proxy).



ssh uses a tty (pty?), but normally you have some in a jail. How do
you start the jail? There should be devfs mounted in the jail.



I'm using a jail created with ezjail from ports. The
jail has both a devfs and fdescfs mounted inside (it uses
the standard jail devfs rules). The ezjail documentation
suggests that it uses the standard /etc/rc.d/jail script
to start jails, a quick look at the source seems to
confirm it.


I use ezjail myself, so this is most probably not the problem.

Bye,
Alexander.

--
God isn't dead, he just couldn't find a parking place.

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-jail@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to [EMAIL PROTECTED]