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]

Date:	Thu, 26 Oct 2006 11:55:25 +0100
From:	David Howells <dhowells@...hat.com>
To:	Jan Dittmer <jdi@....org>
Cc:	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 

Jan Dittmer <jdi@....org> wrote:

> > I can see a few ways to deal with this:
> >
> >  (1) Do all the cache operations in their own thread (sort of like knfsd).
> >
> >  (2) Add further security ops for the caching code to call.  These might
> >      be of use elsewhere in the kernel.  These would set cache-specific
> >      security labels and check for them.
> >
> >  (3) Add a flag or something to current to override the normal security on
> >      the basis that it should be using the cache's security rather than
> >      the process's security.
> 
> Why again no local userspace daemon to do the caching?

Because that reduces the problem to option (1), and then we add context
switches and pushing the metadata in and out of userspace.  In addition, the
cache calls back into the netfs to get information.

I'm guess you're thinking of a halfway-house with userspace deciding which
files to open and then opening the file and telling the kernel to use that
file to back a particular netfs inode, with the kernel handling the actual
read/write ops.  If you are, then this brings us back to the ENFILE problem,
and also raises EMFILE as a new possible problem.  But this time, there isn't
a way to escape the ENFILE problem - you're opening files in userspace.

We could have userspace tell the kernel use a file by name rather than
actually opening it and handing over the fd, I suppose; but you still have the
serialisation issue to deal with.

> That would put the policy out of the kernel. The additional context switches
> are probably pretty cheap compared to the io operations.

It's not just a pair of context switches you have to add in.

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/