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: <1187017052.26008.51.camel@moss-spartans.epoch.ncsc.mil>
Date:	Mon, 13 Aug 2007 10:57:32 -0400
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	David Howells <dhowells@...hat.com>
Cc:	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]

On Mon, 2007-08-13 at 15:51 +0100, David Howells wrote:
> Casey Schaufler <casey@...aufler-ca.com> wrote:
> 
> > I haven't looked into the issues at all and I bet there are plenty,
> > maybe in audit and places outside of the security realm, but this
> > looks like a clean approach from the LSM interface standpoint. Do
> > you want the entire task or just task->security?
> 
> It would probably have to be the task struct, lest the security information
> (for which I've no refcount held) went away whilst I was trying to access it.
> 
> > I could see it either way, but I suspect the task is your best bet. If you
> > call security_act_as() twice, then security_act_as_self() do you pop a
> > stack, or return to the initial state?
> 
> Good point.  I've pondered that.  What I have at the moment partly acts like a
> stack in that I store some of the shifted-out context on the machine stack (in
> struct cachefiles_secctx).  The act-as context should probably be shifted too,
> in addition to the old file-creation SID and the fsuid/fsgid.
> 
> > How about security_act_as(NULL) returning you to the initial state, and
> > dropping security_act_as_self()?
> 
> That would be fine.
> 
> Actually, to address Stephen Smalley's requirements also, how about making
> things a bit more complex.  Have the following suite of functions:
> 
>  (1) int security_get_context(struct sec **_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.
> 
>  (2) int security_push(struct sec *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.
> 
>  (3) int security_pop(struct sec *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.
> 
>  (4) int security_delete_context(struct sec *context)
> 
> 	This deletes a context blob.
> 
> The context blob could then be structured very simply.  Give each loaded LSM
> module an integer index as it is registered.  Having a limit to the number of
> LSM modules would make things simpler.  The blob would then be an array of
> void pointers, one per LSM module, indexed by the integer index for each one.
> It you don't have a limit on the number of LSM modules, you'd also need a
> count of slots in the blob.
> 
> Any LSM module that wanted to implement the above three functions would fill
> in or otherwise use the slot that belongs to it.  Otherwise the slot would
> just be left NULL.
> 
> For example:
> 
> 	context --->+--------+                                    +---------+
> 	            | SLOT 0 |----------------------------------->| SELINUX |
> 	            +--------+                      +--------+    +---------+
> 	            | SLOT 1 |--------------------->| THINGY |
> 	            +--------+                      +--------+
> 	            | ...    |
> 	            +--------+         +-------+
> 	            | SLOT N |-------->| AUDIT |
> 	            +--------+         +-------+
> 
> For Stephen and NFS, he could then generate a context from NFS which nfsd
> could then put in place.  Perhaps any unfilled slot would be ignored by the
> LSM module to which it belonged.

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.

What was the objection again to the original interface, aside from
replacing "u32 secids" with "void* security blobs"?

-- 
Stephen Smalley
National Security Agency

-
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/