enhance security via private TMP/TMPDIR by default

Enrico Scholz enrico.scholz at informatik.tu-chemnitz.de
Thu May 19 06:04:22 UTC 2005


walters at redhat.com (Colin Walters) writes:

>> This CLONE_NEWNS and (related) 'mount --bind' operations are not very
>> well supported by the kernel:
>> 
>> * there does not exist a way to enter an already existing namespace; so,
>>   e.g. two different ssh sessions would have different /tmp directories
>
> Right, but that shouldn't be a problem since you can share data via your
> home directory or a specially-designated scratch area, etc.

It will cause lot of problems when two regular sessions have a different
view of the filesystem. E.g. when session A mounts /media/cdrom, this
will not be available in session B. When B mounts it also, the unmounting
will become funny as the kernel but not processes (detectable with 'fuser
-m') locks this device.

Or, when administrator mounts additional devices in the root-NS, this
will not be reflected in the NS.

Or the /etc/mtab designflaw of 'mount'... it is not NS aware, and although
it causes other problems e.g. in read-only / it was impossible to eradicate
it in all the years.


>> * namespaces are causing problems with automounters
>
> Sounds like a regular bug; I don't think automounters would come into
> play for /tmp anyways?

Think of automounting /home/foo: In root-namespace (where the automounter
was started), nobody accessed this dir and is is not mounted yet.

Now, 'foo' opens a session A which creates a new namespace and tries to
access his homedir. automounter sees that and mounts it; either in the
root-NS (which keeps /home/foo still inaccessible for session A) or in
the NS of session A. In fact, current automounters will do only the
first option, are NS unaware and will be confused by them.

All this is more than I could write in a bugreport; design flaws of
current automounters are well known and documented e.g. in

ftp://ftp-eng.cobalt.com/pub/whitepapers/autofs/towards_a_modern_autofs.txt


>> * 'mount --bind' does not accept/honor options like 'noatime' or 'noexec'
>>   (which could be usefully e.g. to mount $HOME/tmp as /tmp). Patches are
>>   existing but responsible kernel maintainer refuses to apply them :(
>
> noexec's always been virtually useless.

Why? The '/lib/ld-2... /tmp/foo' trick does not work anymore with recent
kernels.


>> * CLONE_NEWNS + 'mount --bind' are not very well documented and it is
>>   often unclear whether strange behavior is expected or not. E.g. it may
>>   happen that '/' and '/..' are pointing to different inodes; dunno if
>>   this is wanted or not.
>
> Hm, so it might confuse tools?

Yes, it breaks e.g. chroot operations of yum.



Enrico
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 480 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050519/9e3ce239/attachment.sig>


More information about the fedora-devel-list mailing list