[Pkg-sysvinit-devel] Bug#345741: Would a restricted form of the INIT_PROG feature suffice?

[Dana How]

On 1/12/06, Thomas Hood <jdthood at yahoo.co.uk> wrote:
> I have an idea.  Instead of allowing an arbitrary program path to be set, we allow
> a _suffix_ to be set.  "telinit -e INIT_SFX=foo ; telinit u" would cause init to exec
> "/sbin/init.foo".  Now, /sbin/init.foo can be a symlink to an executable on another
> filesystem, so this should provide the same capability as INIT_PROG; but because it
> is done via a symlink on the same filesystem as /sbin/init, the administrator has
> control over what init can exec.  If /sbin is on a read-only filesystem and there
> are no /sbin/init.* then the feature is effectively disabled.

This provides the admin no additional control.

Consider this scenario:
(a) Prepare a rw directory "/path" somewhere.
(b) Mount a unionfs over /sbin, adding /sbin and /path as branches
(the latter rw).
(c) Remove /sbin/init. This creates a white-out record in /path .
(d) Add a symlink /sbin/init -> /new_init . This symlink is actually
stored in /path .
(e) Re-exec /sbin/init . We are now running /new_init.
(f) Remove the union branches and umount the union. rm -rf /path .
This only requires ONE rw directory ANYWHERE in the system to work.
Both / and /sbin can be ro.

This example is really the worst of two worlds.
I'm currently using unionfs, but I somewhat suspect it has a bug when
its mountpoint and one of its branches are the same path.
This means I don't want to use the procedure above,
but it must be considered available from a security perspective.

> I can see two possible pitfalls.  First, if /sbin/init.alt is a symlink to /alt/init
> and /sbin/init execs /sbin/init.alt, does this keep /sbin's filesystem busy?  If so
> then we can code init to use readlink(2) to get the target of /sbin/init.alt and
> exec that target instead of /sbin/init.alt itself.
It will not keep /sbin's fs busy
(at least not in the symlink-supporting fs's I know).

> Second, if /sbin/init execs /alt/init (via /sbin/init.alt) and /sbin is unmounted
> then /sbin/init.alt is no longer visible; so init will not be able to re-exec
> itself a second time.  Would this be a problem?
Not being able to re-exec itself a second time would not be a problem
in the exact
sequence that I described to you earlier (possibly in private email).

Unfortunately the suffix idea doesn't help my situation that much.
Remember that I have a ro /sbin and a rw / .
Thus I must do one of the following if I have only INIT_SFX:
(a) /sbin must already have an init.alt symlink pointing to e.g. /etc/init.
If /etc or /etc/init is rw, your security is defeated.  To use this approach,
I must remaster the CD-ROM; at the moment I've been distributing my work
as a post-boot patch,  which can't use this approach.
(b) Create /sbin2 full of symlinks to /sbin's contents, then exchange
names of /sbin2 and /sbin. Now add the symlink.
Again, there is no additional security from the suffix feature.
(c) Use the unionfs procedure above. This entirely bypasses the suffix
feature's security,
and with everything involved (except /path) completely ro.

I think it's a really good idea to try to isolate the smallest & safest change
that will meet a need. I tried to make the patches I submitted small & safe.
But my gut reaction to INIT_SFX is that it forces the client to go through
additional gyrations w/o adding real security.  The real change in the type
of security you're talking about came with the addition of "telinit u" in 1998,
and it was required to be able to update a running init.

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