[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: |
Wed, 08 Jul 2009 09:53:04 +0100 |
User-agent: |
Thunderbird 2.0.0.16 (X11/20080707) |
Hi Svein,
Svein Seldal wrote:
Hi Stuart
[snip]
As with all thing security is a balancing act between the absolute and
preventing normal users conducting what they need to get on with.
Absolutely, I agree. However I do really dislike the usage of world
writeable directories. I consider it a security weakness (me being a
sysop). As proposed I believe there are better methods of giving users
freedom and still maintain decent security. Some may consider this as
unimportant details, but I don't.
We could of course do nothing and leave ltib as is and just leave it to
each paranoid sysadmin (like me) to tighten the security. Personally
don't like this approach, though. I believe that when ltib is asking for
root access and uses this grant to create dirs with 777 permissions is
stretching it a bit far.
Can you explain what liability this exposes for the directories that are
777.
If we do leave ltib as it is today, I think it's reasonable to warn the
users about the 777 directories (in the Faq or similar), don't you
agree? This way they can tighten the security if necessary.
Yes agreed.
What event are you actually worried about occurring?
Well, general security on a multi-user build server is my biggest
concern. 777 permissions and blanket sudo rpm access will be out of the
question.
I can see the issue with sudo, but not with the 777 permissions on a
download area.
As previously mentioned, I have been looking into many internal details
of ltib. The reason for this scrutiny was a combination of factors:
carte blanche sudo rpm access, 777 directories and write access for
ordinary users to /opt. All of my warning lights went on (as I
understand other people has warned of this as well) and investigations
were required. I've actually never had to do these kinds investigations
on any other embedded packaging system before, so I think it fair to
claim ltib is a bit special.
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.
Aside from this we have the common host package install area
(/opt/{ltib|freescale}). This requires sudo root access for the host's
/bin/rpm. The reason for this is that LTIB has to install somewhere and
/opt/{project|vendor} is the right place according to the FSH
http://www.omnisecu.com/gnu-linux/redhat-certified-engineer-rhce/gnu-linux-file-system-hierarchy.htm
So to install there you need root access. Further as explained before
the download cache area and the ltib rpm build area are set to 777.
NOTE: after initial installation you can safely remove the sudo /bin/rpm
entry (as long as you don't need to update).
The reason LTIB allows these few directories to be globally writeable
is because it needs to:
* Users on the same machine need to be able to download to
the common pkgs cache
* Users on the same machine need to be able to install updates
to LTIB, which requires global write access to
/opt/ltib/usr/src/rpm/* as build operations are not root.
My core point is that I propose a fix where you don't need 777
permissions on either of these directories.
The patch for rpm-fs*.rpm does not set the permissions for the two areas
above to root (with 777). Instead it will use the owner of the build
user for these directories. This ensures that the dirs will work when
you're on a single user machine (which most are, I guess). For those of
us on multiuser machines, the sysop would need to change the permissions
accordingly.
Next the patch for ltib properly tests the access to pkg cache (by using
access() instead of just looking at the file permissions). And it will
not change the permissions in case of wrong access.
I will take another look at these and get back to you.
I'm not sure how you intend to share out LTIB on a common server, but
that may not be a great idea if you use NFS etc as this is slow and
permissions/locking problems show up. If you want to share your
download area, your better off to set-up one of your download machines
as a PPP server (http web server) and setup your .ltibrc files
accordingly.
I plan on having each user check out LTIB files (as it is in savannah
CVS) into their locations of own choosing.
However, since the server is common build server, it must use common
controlled host software. Each user will not have write access to
/opt/xxx, nor to the RPM database. This means that normal users will not
be able to upgrade the host tools.
The common pkg cache (the lpp, right?) will be writeable though, but by
using proper group permissions and not 777 permissions.
Okay, sounds good.
PS! I also would like to mention that I am not too fond of the sudo
access scheme which ltib requires. I'm looking at it right now to see if
there is anything that can be done to limit it's usage (as a help to the
community, non assaulting). I'll post this in a later mail, and I hope
it can useful.
I'm not fond of sudo either and lament the fact that many distro allow
by default users to promote themselves to sudo at will.
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.
Thanks for your comments and contribution.
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