Re: enforce_statfs showing leading path
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"
Proposal: automatic jailing of services (rc.d/*) [patch]
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: Proposal: automatic jailing of services (rc.d/*) [patch]
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"
panic on epair destroy in current as of r349853, jail related
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: Running GUI applications in jails
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
Re: Running GUI applications in jails
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: FreeBSD 12.1, vnet jail, and internet access
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: vnet jail for local only or public access
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: vnet jail for local only or public access
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: /etc/jail.d (or jail.conf.d)
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
FYI: OCI-compatible runtime for FreeBSD jails
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
