linux-kernel - Re: [PATCH 00/16] Permit filesystem local caching [try #3]

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: <26859.95417.qm@web36612.mail.mud.yahoo.com>
Date:	Mon, 13 Aug 2007 09:20:23 -0700 (PDT)
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	David Howells <dhowells@...hat.com>,
	Stephen Smalley <sds@...ho.nsa.gov>
Cc:	dhowells@...hat.com, casey@...aufler-ca.com, torvalds@...l.org,
	akpm@...l.org, steved@...hat.com, trond.myklebust@....uio.no,
	linux-fsdevel@...r.kernel.org, linux-cachefs@...hat.com,
	nfsv4@...ux-nfs.org, linux-kernel@...r.kernel.org,
	selinux@...ho.nsa.gov,
	LSM List <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH 00/16] Permit filesystem local caching [try #3]


--- David Howells <dhowells@...hat.com> wrote:

> Stephen Smalley <sds@...ho.nsa.gov> wrote:
> 
> > Seems like over-design - we don't need to support LSM stacking, and we
> > don't need to support pushing/popping more than one level of context.
> 
> It will, at some point hopefully, be possible for someone to try, say, NFS
> exporting a cached ISO9660 mount (CDROM) - in which case, we'd should allow
> for two levels of stack.  If we can pass the displaced context to the caller
> to restore later then that allows for more or less unlimited depth.
> 
> It occurs to me that the following is almost good enough, but not quite:
> 
>   (1) int security_get_context(void **_context);
> 
> 	This allocates and gives the caller a blob that describes the current
> 	context of all the LSM module states attached to the current task and
> 	stores a pointer to it in *_context.

Is this intended to be anything more than a copy of current->security?

>   (2) int security_push(void *context, struct sec **_old_context)
> 
> 	This causes all the LSM modules on the current task to switch to a new
> 	acting state, passing back the old state.  It does not change how
> 	other tasks do things to this one.

I assume that you're talking about the LSM specific data changing,
not the LSM itself.

If you change the task->security information you are definitly going
to change what other tasks can do to the calling task. This is part of
the dark side of label swapping. This is what I was trying to suggest
when I said that if you're going to switch labels you switch to a
system-daemon label, do your work, then change the file label explicitly.
Stephen may have a trick up his sleeve for SELinux, but I don't
expect it to be pleasent.  

>   (3) int security_pop(void *context)
> 
> 	This causes all the LSM modules on the current task to switch to a new
> 	acting state, deleting the old state.  It does not change how
> 	other tasks do things to this one.

Same issues.

>   (4) int security_delete_context(void *context)
> 
> I still need a way to transform the cachefilesd context into the kernel's
> context.  See patch:
> 
>    Subject: [Linux-cachefs] [PATCH 12/16] CacheFiles: Get the SID under which
> 	the CacheFiles module should operate [try #3]
> 
> However, this seems to add a fairly generic tranformation, so that could be
> generalised:
> 
>   (5) int security_xfrm_to_kernel_context(void *from, void **_to);

Woof. What are you transforming from? 

> > What was the objection again to the original interface, aside from
> > replacing "u32 secids" with "void* security blobs"?
> 
> I got the impression that Casey thought much of this was tied to SELinux, but
> rereading his/her

"His" is preferred.

> emails, I'm not so certain.  Maybe that's sufficient. 
> Casey?

I did get the impression that your initial design was focused
on SELinux, and that the implications of alternative LSM modules
had not been very high on your priority list. It's clear from
your responses that you are taking the issue seriously. Thank you.

> However, I've realised a problem (as outlined above) with what I've got.
> Namely its stack isn't necessarily deep enough.  Alternatively, nfsd perhaps
> should suppress caching on what it reads.

That's the really nice thing about cans of worms.
They come in six-packs.



Casey Schaufler
casey@...aufler-ca.com
-
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/