Re: [Ltib] World writable dirs in ltib

[Stuart Hughes]

Svein Seldal wrote:
> Stuart Hughes wrote:
>
> > Yes, I think this is possible, but care would have to be taken.  The 
> > single biggest problem is the initial bootstrapping of the 
> > /opt/{ltib,freescale} area.  This is what needs the sudo /bin/rpm 
> > entry.  The reason being that you have to allow a user to create a 
> > common directory in /opt that they would not otherwise have permission 
> > to do. Maybe a compromise would be to change the sudo test in LTIB to 
> > say something like:
> >
> > To initially install LTIB you must get a sysadmin who has sudo 
> > /bin/rpm permission to install the common areas, or you will need to 
> > have this permission yourself.   Once installed, to use LTIB as a 
> > user, you only need sudo /opt/ltib/usr/bin/rpm permission.
>
> I previously did an investigation of the initial hostcf bootstrap and as 
> far as I understand it consists of 5 parts:
>     1) Using host's rpmbuild to build rpm-fs package
>     2) Install rpm-fs using host's rpm
>     3) Update rpm-fs using opt rpm

This is just updating the opt rpm database so rpm-fs is shown.

>     4) Build other host packages using opt rpmbuild
>     5) Install other host packages using opt rpm
>
> Now, the intersting thing is that sudo /usr/bin/rpm is ONLY needed for
> item no 2. So why setup /usr/bin/rpm with NOPWD just for this once? Just 
> let the user enter his sudo password.

The reason is that LTIB installs to a large number of distros and many 
(Fedora etc) don't have sudo enabled for users by default.  So overall 
the least amount of support for me is to just blanket tell people to 
setup sudo.  Whether or now someone has to type in their user password 
doesn't really make that much difference IMHO as they have the power to 
abuse if they want to (which is the main issue).

> I would appreciate one thing though: Prior to running sudo, I'd more be 
> more comforted(?) by having a text message telling the user what is 
> about to happen. Something like:
>
> "Warning: I am about to run /usr/bin/rpm as root to install
>   /tmp/rpm-nosse1/RPMS/i686/rpm-fs-4.0.4-1.i686.rpm
> under /opt/ltib. I have checked the rpm to make sure it does not clobber 
> your system.
>
> sudo rpm --root / --dbpath /tmp/rpm-nosse1/rpmdb --ignorearch -ivh 
> --force --nodeps --excludedocs  --define '_tmppath 
> /home/nosse1/vitalsim2/imx/upstream/ltib.build/tmp' 
> /tmp/rpm-nosse1/RPMS/i686/rpm-fs-4.0.4-1.i686.rpm
> "

I could do something like that.  I think it would have to occur when 
rpm-fs is being built/installed and display the message and run after a 
suitable timeout.  The reason is I want --batch (unattended) mode to 
continue to work.


> It may seem obvious, but I were not aware of the clobber checks until I 
> manually skimmed through the ltib script!

Fair point.

> Coming back to the hostcf building process: When the rpm-fs package is 
> installed into /opt using the host's rpm, you don't actually need to 
> install any of the other host packages to be able to build them.

Correct.  Once rpm-fs is installed you could remove the sudo entry for 
it.  As long as opt rpm-fs does not get removed you don't need it.

> I made a test the other day, were I didn't install anything, just build.
> This way I got a handful of .rpm files in /opt/ltib/src/rpm/RPMS/...
> which could be installed in one singular shebang. I use this to
> distribute binary host tools across different homogeneous machines. See
> the attached script. (For that scenario it would have been nice with a 
> --build-only feature of --hostcf.)

What I'm not sure about is whether some of the host rpms have 
dependencies on earlier ones being installed.  If not then yes this 
could be a good approach.

> > This would allow you to limit the sudo hole to just 
> > /opt/ltib/usr/bin/rpm.  As we build this, we could control the base 
> > prefixes into which it can install.
>
> Are there any limitations inside the rpm application to limit where it
> can install packages?  E.g.
>
> $ sudo /opt/ltib/usr/bin/rpm --root / --dbpath /var/lib/rpm --prefix /
> -ivh some.rpm

No, in this incantation becasue --root is /, this means that it is 
possible to install an rpm anywhere.  For LTIB that's not too bad as we 
have the clobber checks, but outside is where someone could say:

$ sudo /opt/ltib/usr/bin/rpm --root / -ivh some_unauthorised_rpm

> is still possible and destructive to the system, right?

Outside ltib, yes in theory.  In reality the user would have to be 
malicious (on an rpm based host at least) as without --force (and other 
options) rpm will prevent you clobbering files installed by other rpms.

> At some point it boils down to trust. If we make a security auditer, who
> audits the auditer? So in practice this isn't a problem I guess.

Agreed.  I think all you can do is make reasonable safeguards.

> I think the most likely mistake is if a user manually runs
> "/opt/ltib/usr/bin/rpm -ivh faulty_pkg.rpm". Since the command promt
> lines for rpm operations inside ltib are very long, I doubt this will be
> done manually though.

That's the biggest risk, someone "trying to be clever" and for example 
thinking they could upgrade a package (openoffice) and actually cause a 
spiral of death on that machine.

Having said that, on many popular distros these days they can do:
sudo yum update .. or sudo apt-get upgrade or whatever, they type in 
their password and they can install whatever they want (good or bad).

Security is a difficult balance to get right.