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

[Dana How]

On 1/3/06, Thomas Hood <jdthood at yahoo.co.uk> wrote:
> 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?
Yes, using "ldd $(which init)" or "lsof -b -w -p 1" will show you _all_ the
libraries /sbin/init has opened,  which may as well be on
filesystem(s) I want to umount.
So we have these options:
(a) use a static init. Must be pre-stored somewhere besides the ro
/sbin I want to umount.
Requires extra space on CDROM image for static init, extra space on ramdisk
for linuxrc (in the initrd) to pre-store the init I intend to run
(which must always be there in the ramdisk, since I can't re-exec
later in this scenario).
Since a static init is at least 0.5MB, I must remove something else
from CDROM image.
(b) use an INIT_PROG-like re-exec. Make INIT_PROG point to a 3-line bash
script which sets LD_LIBRARY_PATH and exec's the real new init.
Now I have an init using an executable and libraries wherever I want.
I consider an extra 3-line script a very acceptable level of futzing ;-)

So,  at some cost in space (which is usually considered quite
important in live CDs),
a static init is a help,  but only if it is stored in e.g. a ramdisk
from startup to shutdown.
A solution more like INIT_PROG does what I want w/o the extra costs.

> 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.
OK, this seems like a valid concern to me.

I can think of three possible alterations to my patch:
(1) "telinit -e var=" causes var to get stuck permanently in the unset state.
I don't like this; seems too special-case and limited-use.
(2) We follow bash's ideas about a "restricted shell" and add a hardlink
to init called rinit, as well as a -r switch. This mode would at least
prevent INIT_PROG
from being altered.
(3) Not only support "telinit -e var=val" but "telinit -e var:=val" as well.
Once the 2nd occurs, the value cannot be altered.
(This actually seems to be useful, especially if the env gets used more.)

Then the security conscious admin does one of these things when he
makes / , /sbin
ro.  Or, better, the startup scripts always do one of these,  and someone needs
to modify them for a more flexible setup (none of these proposals
prevent telinit u
from working as it does now, which is needed to upgrade /sbin/init).

> I think that we should ask about this on debian-security.
Makes sense to me. The three proposals above provide a mechanism
to revert back to the current state,  which I hope will be the kind of
thing debian-security
woudl like to see.

Is there anything else I should do now? Modify my patch for option (3) above?

Thanks,
--
Dana L. How  danahow at gmail.com  +1 650 804 5991 cell