[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ltib] World writable dirs in ltib
From: |
Stuart Hughes |
Subject: |
Re: [Ltib] World writable dirs in ltib |
Date: |
Thu, 09 Jul 2009 10:14:49 +0100 |
User-agent: |
Thunderbird 2.0.0.16 (X11/20080707) |
Hi Svein,
Svein Seldal wrote:
Stuart Hughes wrote:
Can you explain what liability this exposes for the directories that
are 777.
Well, I have to admit I don't have a particular threat in mind. From all
security training I've had, I've always been told 777's are one of big
no-nos. Please take a look at this:
http://docstore.mik.ua/orelly/networking/puis/ch11_06.htm
However, if you can assume complete trust of all users on the machine,
then the risk is less (because you need basic access to the machine &
directory to be able to do anything). But also keep in mind that any
services running has the potential of being misused/hacked into
something malicious and can directly exploit the given dirs. (Ok. I
admit, you don't run high-exposed web DMZ on an internal development
server. So I'm paranoid. :) I yield. )
Some other systems to require root access. If they don't they do
less. As I explain before the requirement for sudo root is during rpm
install (only). This is needed to build an accurate NFS image that
can be booted, which for development is the most productive
environment as it allows incremental live updates to the target. Now
you could come up with an NFS deployment scheme that avoids device
nodes, but that would need initramfs and mandate udev. There are
often times where this requirements are not acceptable (older kernels,
or low power CPU that need fast boot). Furthermore the
permissions/owners/groups would not be exactly right and likely cause
problems. So hopefully you can understand the need for this, removing
some sudo root access for rpm install would reduce the capability of
the tool.
Yes. I agree and understand. Security shouldn't be so tight that it
squeezes the developers. I'm a developer too, so I hate it when that
happens.
I hope I've explained a little about about why LTIB needs this. If
you can figure out a scheme that avoids this that would be very helpful.
Thank you for your insights.
Alas. As an update I've investigated a bit. I had a hope that a fakeroot
and fakechroot jail could reduce the requirements for target
installation sudo. This way rpm could be alluded to think it has root
access, but in reality it does not (hence no sudo would be required).
But there are three obstacles that effectively stops this scheme:
*) rpm doesn't behave well in a fake[ch]root environment. It's using a
syscall which is making the rpm -ivh operation fail. This is probably
patchable given enough effort.
*) fakechroot lets you create your own device nodes in the jail.
Unfortunately these device nodes are only visible *inside* the jail.
Outside (from other application, say NFS) they are just empty ordinary
files!
*) rootfs would with fakechroot be using the uid for the user and not
root. I have not investigated this, but allegedly NFS tend to become
slower unless the NFS fs is root. But I believe it is possible to make a
host uid 1000 -> uid 0 translation while sharing, right? (Now it does
not really matter, anyway.)
Since the device nodes are only useful outside the jail (e.g. via. NFS
sharing), then the jail is useless! I totally agree that we should not
limit the user's ability to create device nodes and such.
Yes, unfortunately fakeroot doesn't help. Note though, when rpm builds
it is running as the normal user but it behaves like fakeroot in as much
that you can create binary rpms that have root ownership and also device
nodes. The problem really is if you actually want to install them you
must be root.
One way to avoid this as I mentioned before is to say "no more NFS
deployment", in which case you could use rpm2cpio to extract files as
non-root and then used the current ramdisk/jffs2 deployment methods.
The problem with this though is:
* It's a non trivial change
* NFS deployment is the most productive development environment
* The root file system produced is not correct wrt owners/groups etc.
Let me throw out one last idea in this. It might be stupid, but please
hear me out:
Giving each developer needs NOPWD sudo /opt/ltib/xxx/rpm (and to to
/usr/bin/rpm if hostcf) it will effectively mean that each user _can_
install any rpm on the system. Now, I am aware that ltib tries to make
sure the rpms wont clobber the system, but the user can (deliberately or
mistakingly). Or there could be bugs in ltib.
Bugs in LTIB should not worry you too much because:
* There are many check.
* hostcf is the most vulnerable, but the least used (with checks)
* For the target rpms, when they install you are chrooted to rootfs,
so there's no chance of installing outside this.
* So far (I acknowledge the possibility) this has not occured.
The real risk is that outside LTIB someone could abuse their sudo
ability to run rpm and install whatever the want on the system (e.g.
download an rpm and install it themselves). However:
* For most companies they would risk dismissal
* If they have physical access to a machine, they can bypass any
security as they can boot the machine any way they like
for example a live rescue CD.
As a sysop I would like to make sure that the files rpm is writing to
limited to inside /opt/xxx or the calling user's home directory. Could
it be an idea to write a rpm wrapper/sanitizer which ensures no access
outside these permissible areas? This wrapper is then used in the sudo
configuration instead of a direct reference to rpm. Maybe even you don't
need sudo if it were suid root. In both cases the wrapper would have to
be installed and run by root for it to make sense. Any sysop can then
limit the security audit to this wrapper to be confident the system
integrity is maintained.
(A better approach would be to inject filters to the system library
(like fakeroot does) to limit/stop any wrongful write/change. Hmm. There
must be a security hardening software out there that can do that...)
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.
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.
Just a thought.
Regards, Stuart
- [Ltib] World writable dirs in ltib, Svein Seldal, 2009/07/06
- Re: [Ltib] World writable dirs in ltib, Svein Seldal, 2009/07/09
- Re: [Ltib] World writable dirs in ltib, Stuart Hughes, 2009/07/10
- Re: [Ltib] World writable dirs in ltib, Svein Seldal, 2009/07/10
- Re: [Ltib] World writable dirs in ltib, Stuart Hughes, 2009/07/10