--- David Howells [EMAIL PROTECTED] wrote:
Casey Schaufler [EMAIL PROTECTED] wrote:
Sigh. So it's not only SELinux specific, but RedHat specific as well.
*Blink*. How did you come to that conclusion?
(3) The cache driver wants to access the files in the cache, but it's
On Mon, 2007-08-13 at 11:54 +0100, David Howells wrote:
Casey Schaufler [EMAIL PROTECTED] wrote:
Sigh. So it's not only SELinux specific, but RedHat specific as well.
*Blink*. How did you come to that conclusion?
(3) The cache driver wants to access the files in the cache, but it's
On Mon, 2007-08-13 at 15:51 +0100, David Howells wrote:
Casey Schaufler [EMAIL PROTECTED] 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
Casey Schaufler [EMAIL PROTECTED] 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
Stephen Smalley [EMAIL PROTECTED] 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
--- Stephen Smalley [EMAIL PROTECTED] wrote:
On Mon, 2007-08-13 at 15:51 +0100, David Howells wrote:
...
Actually, to address Stephen Smalley's requirements also, how about making
things a bit more complex. Have the following suite of functions:
(1) int
Casey Schaufler [EMAIL PROTECTED] wrote:
(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
