[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ltib] World writable dirs in ltib

From: Svein Seldal
Subject: Re: [Ltib] World writable dirs in ltib
Date: Thu, 09 Jul 2009 12:04:03 +0200
User-agent: Thunderbird (X11/20090608)

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
    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.

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
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/' /tmp/rpm-nosse1/RPMS/i686/rpm-fs-4.0.4-1.i686.rpm

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

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.

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.)

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

is still possible and destructive to the system, right?

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.

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.

- Svein

Description: Bourne shell script

reply via email to

[Prev in Thread] Current Thread [Next in Thread]