Re: mount_nullfs: /var/run/log: must be either a file or directory

On Fri, 7 Jul 2023 at 13:11, Mina Galić <freebsd@igalic.co> wrote:

> Hi folks,
>
> "recently", we added support for null-mounting single files:
>
>
> https://freshbsd.org/freebsd/src/commit/521fbb722c33663cf00a83bca70ad7cb790687b3
>
> This code restricts the mountable … thing to:
>
>         if ((lowerrootvp->v_type != VDIR && lowerrootvp->v_type != VREG)
> || …
>
>
> As the author of the abandoned https://reviews.freebsd.org/D27411
> which attempted to add facility to syslog's rc to provide (selected)
> jails with a log socket, it was pointed out to me that this is a big
> security risk: https://reviews.freebsd.org/D27411#882100
>
> so I was wondering if null mounts are the same kind of security
> hazard, or if not allowing sockets is just the oversight of a
> first approximation of this patch?
>

Mounting anything into a jail needs to be done carefully. Clearly null
mounting /sbin into an untrusted jail allows all kinds of shenanigans to
happen but I don't see a huge problem with mounting e.g. a data volume or a
config file into a jail. Care needs to be taken at the point when the
object is mounted to defend against symlinks in the jail's chroot causing
the mount point to change to a surprising location outside the chroot. In
ocijail, I added code to resolve symlinks in the context of the jail's
chroot to avoid this.

I also think it's important to perform any mounts or other configuration
strictly before the jail is started - for OCI containers under podman or
containerd, this may happen after the jail is created but strictly before
anything in the container image is executed. Conversely, unmounting happens
strictly after the jail is removed.

In principle, I don't think it's a problem to mount sockets or fifos into a
jail but one of the points made in your diff that allowing jails to connect
to the host syslogd is a potential risk is a good one.

Doug.