Re: Call for Foundation-supported Project Ideas

From: Alexander Leidinger via freebsd-hackers <>
Date: Thu, 25 Nov 2021 07:58:42 UTC
Quoting Miroslav Lachman <> (from Thu, 25 Nov 2021  
01:49:16 +0100):

> Alexander Leidinger posted proposal in 2019 "automatic jailing of  
> services (rc.d/*)" [1] with patch [2]. This seems useful and easy to  
> implement in base to me.

I have a patch. I consider it an useful idea. I have 1 service on my  
server in the basement which is using it. I have converted a few more  
services (basically just the rc scripts to make use of the feature),  
but don't use them at home (I converted some easy ones, but have no  
use for them at home). I have run into some cases, where this doesn't  
work on the rc-level, as the patch I have for this feature I have made  
in a minimal-invasive way. But this part of the rc framework is not  
really suited for what I want to use it for (currently I use the  
fast*/force*/one* part to add a jail* prefix, but this runs into  
issues if you want to use e.g. onestart with a service which is  
supposed to run in a jail automatically).

If someone who has more intimate knowledge about rc.subr comes up with  
an idea how to implement it in a better way, I'm all ears...

My patch (last regenerated Apr 2020):

> As far as I know, Alexander also have patch to allow run Xorg in jail.

The only reason this is not committed is, that there was feedback in a  
way that I shall not use a jail-parameter (currently  
allow.kmem_access) to enable the feature. This can be understood in  
two ways:
  1) do not use the corresponding KPI
  2) continue to use the KPI, but add some code to jail(8) to  
translate a new kind of argument to the corresponding  
allow.kmem_access KPI

In both cases the security aspect is the same, this makes the host  
completely accessible to any program run as root in the jail which has  
this enabled, it's just a different interface to enable it. Personally  
I do not see a difference between "--new-way-of-enabling-this-feature"  
or "allow.kmem_access" (or  
"allow.give_mem_access_to_complete_host_and_compromise_security"). As  
such I do not intend to write any code for 1) or 2).

My patch (last regenerated Apr 2020, only the first part, the file  
contains some more unrelated changes):

> [1]  
> [2]


-- PGP 0x8F31830F9F2772BF  : PGP 0x8F31830F9F2772BF