linux-kernel - Re: Security issues with local filesystem caching

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8649.1161859544@redhat.com>
Date:	Thu, 26 Oct 2006 11:45:44 +0100
From:	David Howells <dhowells@...hat.com>
To:	Al Viro <viro@....linux.org.uk>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, sds@...ho.nsa.gov,
	jmorris@...ei.org, chrisw@...s-sol.org, selinux@...ho.nsa.gov,
	linux-kernel@...r.kernel.org, aviro@...hat.com
Subject: Re: Security issues with local filesystem caching 

Al Viro <viro@....linux.org.uk> wrote:

> > > Currently, CacheFiles temporarily changes fsuid and fsgid to 0 whilst
> > > doing its own pathwalk through the cache and whilst creating files and
> > > directories in the cache.  This allows it to deal with DAC security
> > > directly.  All the directories it creates are given permissions mask
> > > 0700 and all files 0000.
> > 
> > That seems sensible and fine. It is precisely why we added a separate
> > fsuid in the first place so that the user space nfsd could take on an fs
> > identity without breaking signal and other security based forms.
> 
> I see a problem with that; not sure if that's what Christoph is objecting
> to.  What about access to cache tree by root process that has nothing
> to do with that daemon?  Should it get free access to that stuff, regardless
> of what policy might say about access to cached files?  Or should we at
> least try to make sure that we have the instances in cache no more permissive
> than originals on NFS?

Well, if the data is being copied to where userspace can get at it, and if MAC
is disabled, then it doesn't matter: root can always gain access if it wants
to, no matter what the DAC-related attributes are.

I'm quite happy to attach security data to the files in the cache, and use MAC
if it's available, but most of the time, it can't be the MAC-related attributes
of the process in who's context we're running.

David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/