Re: [Ltib] World writable dirs in ltib

[Stuart Hughes]

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