On Mon, 2008-01-14 at 14:06 +, David Howells wrote:
David Howells [EMAIL PROTECTED] wrote:
Okay... It looks like I want four security operations/hooks for cachefiles:
FYI, I added the following vectors:
# kernel services that need to override task security
class
Stephen Smalley [EMAIL PROTECTED] wrote:
(3) Check that the kernel may create files as a particular secid (this
could be specified indirectly by specifying an inode, which would
hide the secid inside the LSM).
I don't think this check is on the kernel per se but rather the
On Tue, 2008-01-15 at 16:03 +, David Howells wrote:
Stephen Smalley [EMAIL PROTECTED] wrote:
(3) Check that the kernel may create files as a particular secid (this
could be specified indirectly by specifying an inode, which would
hide the secid inside the LSM).
I
On Tue, 2008-01-15 at 10:10 -0800, Casey Schaufler wrote:
--- David Howells [EMAIL PROTECTED] wrote:
Stephen Smalley [EMAIL PROTECTED] wrote:
(3) Check that the kernel may create files as a particular secid (this
could be specified indirectly by specifying an inode, which
I must say I personally prefer the apparmor approach. But I'd recommend
you get together and get this piece pushed on its own, whichever version
you can agree on. Yes it needs a user, but at this point I would think
both tomoyo and apparmor have had enough visibility that everyone knows
the
Stephen Smalley [EMAIL PROTECTED] wrote:
The cache files are created by the cachefiles kernel module, not by the
userspace daemon, and the userspace daemon doesn't need to directly
read/write them at all
That is correct.
(but I think it does need to be able to unlink them?).
Indeed.
The
--- David Howells [EMAIL PROTECTED] wrote:
Stephen Smalley [EMAIL PROTECTED] wrote:
The cache files are created by the cachefiles kernel module, not by the
userspace daemon, and the userspace daemon doesn't need to directly
read/write them at all
That is correct.
(but I think it
Check the starting keyring as part of the search to (a) see if that is what
we're searching for, and (b) to check it is still valid for searching.
The scenario: User in process A does things that cause things to be
created in its process session keyring. The user then does an su to
another user
These patches add local caching for network filesystems such as NFS.
The patches can roughly be broken down into a number of sets:
(*) 01-keys-inc-payload.diff
(*) 02-keys-search-keyring.diff
(*) 03-keys-callout-blob.diff
Three patches to the keyring code made to help the CIFS
Increase the size of a payload that can be used to instantiate a key in
add_key() and keyctl_instantiate_key(). This permits huge CIFS SPNEGO blobs to
be passed around. The limit is raised to 1MB. If kmalloc() can't allocate a
buffer of sufficient size, vmalloc() will be tried instead.
Allow the callout data to be passed as a blob rather than a string for internal
kernel services that call any request_key_*() interface other than
request_key(). request_key() itself still takes a NUL-terminated string.
The functions that change are:
request_key_with_auxdata()
Provide an add_wait_queue_tail() function to add a waiter to the back of a
wait queue instead of the front.
Signed-off-by: David Howells [EMAIL PROTECTED]
---
include/linux/wait.h |2 ++
kernel/wait.c| 18 ++
2 files changed, 20 insertions(+), 0 deletions(-)
diff
The attached patch causes read_cache_pages() to release page-private data on a
page for which add_to_page_cache() fails or the filler function fails. This
permits pages with caching references associated with them to be cleaned up.
The invalidatepage() address space op is called (indirectly) to
Change all the usages of file-f_mapping in ext3_*write_end() functions to use
the mapping argument directly. This has two consequences:
(*) Consistency. Without this patch sometimes one is used and sometimes the
other is.
(*) A NULL file pointer can be passed. This feature is then made
Add a function to install a monitor on the page lock waitqueue for a particular
page, thus allowing the page being unlocked to be detected.
This is used by CacheFiles to detect read completion on a page in the backing
filesystem so that it can then copy the data to the waiting netfs page.
Fix a memory leak whereby multiple clientaddr=xxx mount options just overwrite
the duplicated client_address option pointer, without freeing the old memory.
Signed-off-by: David Howells [EMAIL PROTECTED]
---
fs/nfs/super.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git
The attached patch makes it possible for the NFS filesystem to make use of the
network filesystem local caching service (FS-Cache).
To be able to use this, an updated mount program is required. This can be
obtained from:
http://people.redhat.com/steved/fscache/util-linux/
To mount an
Separate caching by superblock, explicitly if necessary. This means mounts of
the same remote data with different parameters do not share cache objects for
common files. The administrator may also provide a uniquifier to further
enhance the uniqueness.
Where it is otherwise impossible to
Hello.
Serge E. Hallyn wrote:
I must say I personally prefer the apparmor approach.
No problem.
But I'd recommend
you get together and get this piece pushed on its own, whichever version
you can agree on.
TOMOYO can use AppArmor's patch.
Yes it needs a user, but at this point I would think
On Tue, 15 Jan 2008, David Howells wrote:
The SELinux base code will also need updating to have the security class, lest
the following error appear in dmesg:
context_struct_compute_av: unrecognized class 69
Alternately, what's needed is a newer policy which supports unknown
On Jan 15, 2008, at 18:46, David Howells wrote:
(*) 01-keys-inc-payload.diff
(*) 02-keys-search-keyring.diff
(*) 03-keys-callout-blob.diff
One vaguely related question: Is there presently any way to adjust
the per-user max-key-data limit? I've been tinkering with using the
new-ish MIT
21 matches
Mail list logo
