Re: [Ltib] World writable dirs in ltib

[Svein Seldal]

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.


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.

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


- Svein