[Pkg-sysvinit-devel] Re: Bug#345741: Please add INIT_PROG env var to override re-exec'ing from /sbin/init

[Thomas Hood]

First of all, let me say that I very much support what you are trying to do.
We will try to help you.

The workarounds you describe involving futzing with /sbin are certainly ugly.

One idea that you didn't address was static linking of executables.
This idea was put forward in #338299.  Would static linking help you?
If so, what executables would have to be statically linked?  If not,
why not?


Dana How wrote:
> Concerning the security issues.  In order to abuse this feature,
> one needs access to /dev/initctl, the pipe through which any PROG_INIT
> setting would flow. (This pipe has permissions 0600 on my system.)
> Any one with such access could issue "telinit u" already and
> re-exec init from /sbin/init. If / and/or /sbin/. are rw,  then we know from
> the workarounds this re-exec could be intercepted.
> So the only new area of possible concern is when / and /sbin/. are both ro.
> (Perhaps SELinux changes these deductions, but I'm not experienced with it.)
> 
> I've never seen that in any Linux or Unix installation I've used.
> Perhaps this could be the case in an embedded version of Linux,
> but the security concerns there are probably very different anyway.


Basically the concern expressed by Petter is that the INIT_PROG feature
removes part of the security an admin tries to create when he makes the root
filesystem (which normally includes /sbin) read-only.  It is true that admins
can't yet easily mount the root file system read-only, but this is an option
that Debian wants to provide sooner or later.

I think that we should ask about this on debian-security.
-- 
Thomas