History..  A couple years ago I left MSWormOS behind, and jumped to
Mandrake Linux. Back on Lose98, everything effectively ran as root.  Since
switching, I've been a good boy and learned NOT to run stuff as root,
except where necessary.

With that in mind, I've become increasingly uncomfortable running urpmi,
downloads and all, from root.  I don't surf the web as root, and for good
reason, I expect most will agree.  I understand the need for root for the
installation steps, but why must the files be downloaded as root?  That
seems like far less than a secure solution, from here.  Having been on
this list a bit over a full release cycle now, I've waited for this to
come up, as I was SURE I was missing something obvious and if I just kept
quite someone else would raise the issue and I'd be able to learn.. 
However, that hasn't happened, and at the expense of looking foolish for
overlooking the obvious, I'm now raising the issue, as I'm becoming
increasingly uncomfortable with the current situation.

Looking over the current situation, with urpmi requiring root, while some
other "safer" functions such as urpmq are available for use as a user, and
with what I've managed to understand from other packages and what runs as
root and what doesn't in the rest of the distrib, I've come up with a
proposed solution, that of running only the install functions as root,
with the rest of the procedure, particularly the downloads, handled as
an ordinary user.

1) Split urpmi into two different steps.  A normal user privileged
step would query the rpmdb for current versions, figure out the updates
available, and download them.  A second step requiring root would then do
the actual installs.

2) Create an urpmi user account to execute the first step and own the
local hdlists, config files, and caches.  This would keep update
functionality separate and prevent possible security issues with basically
everything else the (human) user might be running having access to the
updates in process, if this step were to be handled by a normal user
account operating non-core and possibly not completely trusted
applications.

3) Set up the rest of the urpm* family (.update, .add/remove-media,
etc.) to use the same user.

4) Set up the main urpmi script such that when invoked as it is now (must
be root) it runs urpmi-user portion first, waiting for it to complete,
then runs the root-user portion.

Discussion:  Some may argue that this won't provide any more security
anyway, as any interference could just be done to the downloaded packages
instead.  While this might be true  as far as the package data itself
goes, it doesn't see the larger possibilities for mischief.  1)  If there
exists a vuln in curl or wget, it might be possible to trigger arbitrary
execution of code with a specially designed packet inserted into the d/l
stream.  It's possible a third party could insert this, so it wouldn't
have to be the ideally trustworthy mirror server.  Should this occur, it'd
be far better for said execution to run as an unprivileged user than as
root itself.  2) Packages are now for the most part signed, such that
direct interference with them would be detectable.  Thus, that's less
possible, as would be interference with them from an execution vuln in
ordered to get more privileges during the install phase.  3)  That has the
effect of limiting security issues to (1), arbitrary code execution during
the d/l, which as I said, is far better limited to a non-privileged user
than running as unrestricted root.

I still have a difficult time believing I'm the first one to see this,
which means I'm probably missing something obvious.  However, in
contemplating this issue, I haven't stumbled upon it in several months, so
either this is the better security solution I believe it to be (and is as
practical to implement as I suppose it should be), or it's going to take
someone else to explain to me what I am missing.  <g>  In either case,
here's the suggestion, for what it's worth.  It's pretty much the
beginning of a new development cycle, so probably as good a time as it
gets, to post this.

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin



Reply via email to