[Pkg-sysvinit-devel] 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:
> Petter Reinholdtsen wrote:
> > This sounds like a security issue.  If the admin made / read-only, and
> > someone is able to gain enough privileges to talk to init but not to
> > remount the file system, they could re-exec init with a binary they
> > provide instead of the binary the machine administrator intented to
> > run.  Am I wrong?  If I am right, I believe we should not implement
> > this feature.
>
> I had the same thought.  At the very least the feature creates a new angle
> of attack which needs to be thought about.  Whether the feature really could
> create a vulnerability, I am not qualified to judge.
>
> This is not to say that we definitely should not implement this.  But it does
> mean that there should be strong arguments in favor of adding the feature.
> Is "telinit u" with the new feature _needed_ to deal with these cases?  What
> are the alternatives?

Petter's initial comments were in response to part of my bugreport:
> However, if /sbin/init is on a read-only filesystem,
> or you want to redirect init to be running from a different
> filesystem because you need to umount /sbin ,
> this feature is inadequate.

Thanks for your observations.  Let me speak first to what this would
be used for, and then to the security aspects.

At the moment, I'm interested in running CD-ROM (i.e., isofs-based)
live Linux distributions smoothly on WinXP laptops w/o disturbing the
Windows setup.  In the future I'd like to run Linux, probably again live CD
versions, from a USB key.  The common elements here are
(a) use of iso9660, squashfs, cramfs, cloop, etc., which provide ro filesystems
(b) removable media
(c) keeping the result as similar to the original distribution as possible.

The specific scenarios I'd like to address are:
(1) Mount the system from a compressed image in a file in an NTFS partition.
Mount the home directory, and other rw directories, from an ext3 image
in a fiile in the same NTFS partition. This requires no repartitioning or other
modification of the WinXP system, just the addition of WINGRUB and some
image files. The need for compression makes a lot of things ro.
Note that rw loopback mounts to files in NTFS are safe (since the
image file doesn't change in length). Unfortunately, to avoid the NTFS driver
marking the partition as dirty and causing a lengthy CHKDSK when booting
Windows, we need to cleanly umount _all_ filesystems loop-mounted on
top of NTFS if any were mounted rw (as well as the NTFS partition itself).
This means umount'ing /sbin, among other things.
(2) Running from a real CDROM. Now we want to shutdown and eject the thing,
but eject is a binary on the CDROM! This conundrum is solved by using
"eject -m" (-m means eject the media but umount the fs on top of it)
and relying on the (page? name?) cache(s) to still contain the proper parts
of eject, /sbin/init, libc, bash, etc. As shutdown scripts become more
complicated
to deal with loop mounts, unionfs, etc., this seems more and more dangerous,
and I've seen some of my attempts die mysteriously.
(3) Running from a USB key which could be removed. I'm not doing this right now,
but this would benefit from at least the features I'm discussing,
for similar reasons.

In (1) and (2), /sbin/. would be ro; in (3), maybe rw.
The real issue is not that /sbin/. is ro, but that I want to umount it safely.
The ro part makes work-arounds more difficult.

Here are some example work-arounds in the absence of
being able to say "telinit -e PROG_INIT=/new_path/init ; telinit u":

If /sbin/. is rw, then we just move files around in /sbin/. .
Perhaps /sbin/init becomes a bash script which undoes this
re-arrangement (destroying itself) and calls the desired new init.

If /sbin/. is ro but / is rw, then create /sbin2 and populate it with symlinks
to the contents of /sbin . Switch /sbin and /sbin2 (actually, those new
symlinks pointed to /sbin2). Now we are in the previous paragraph.

If / is ro, we are probably stuck, unless we previously arranged something.

These work-arounds are pretty hokey and require surgery on /sbin ,
but they do work.  I hope you view supporting PROG_INIT as a little
more sane than using a full-blown fake /sbin populated with symlinks,
just for this ability.

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.

I hope this is sufficient detail to see some of the utility of PROG_INIT.
LiveCDs have been very helpful in propagating Linux,
and I think the ability to put a full Linux distribution on a WinXP
system (laptops in my case) w/o major surgery like repartitioning would
also be helpful (scenario 1 above).  Unfortunately NTFS support is iffy
and I really need to make sure everything is cleanly umount'd,
including whatever is containing /sbin .  As a side note, there apparently
was another bug (338299) where someone mentioned he wanted to
umount /sbin , but he never responded to my email for more info.

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