| Age | Commit message (Collapse) | Author |
|
- added typedef unsigned int __nocast gfp_t;
- replaced __nocast uses for gfp flags with gfp_t - it gives exactly
the same warnings as far as sparse is concerned, doesn't change
generated code (from gcc point of view we replaced unsigned int with
typedef) and documents what's going on far better.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
|
|
This patch removes the inode_post_link and inode_post_rename LSM hooks as
they are unused (and likely useless).
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
This patch removes the inode_post_create/mkdir/mknod/symlink LSM hooks as
they are obsoleted by the new inode_init_security hook that enables atomic
inode security labeling.
If anyone sees any reason to retain these hooks, please speak now. Also,
is anyone using the post_rename/link hooks; if not, those could also be
removed.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
The following patch set enables atomic security labeling of newly created
inodes by altering the fs code to invoke a new LSM hook to obtain the security
attribute to apply to a newly created inode and to set up the incore inode
security state during the inode creation transaction. This parallels the
existing processing for setting ACLs on newly created inodes. Otherwise, it
is possible for new inodes to be accessed by another thread via the dcache
prior to complete security setup (presently handled by the
post_create/mkdir/... LSM hooks in the VFS) and a newly created inode may be
left unlabeled on the disk in the event of a crash. SELinux presently works
around the issue by ensuring that the incore inode security label is
initialized to a special SID that is inaccessible to unprivileged processes
(in accordance with policy), thereby preventing inappropriate access but
potentially causing false denials on legitimate accesses. A simple test
program demonstrates such false denials on SELinux, and the patch solves the
problem. Similar such false denials have been encountered in real
applications.
This patch defines a new inode_init_security LSM hook to obtain the security
attribute to apply to a newly created inode and to set up the incore inode
security state for it, and adds a corresponding hook function implementation
to SELinux.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Of this type, mostly:
CHECK net/ipv6/netfilter.c
net/ipv6/netfilter.c:96:12: warning: symbol 'ipv6_netfilter_init' was not declared. Should it be static?
net/ipv6/netfilter.c:101:6: warning: symbol 'ipv6_netfilter_fini' was not declared. Should it be static?
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Here's a small patch against 2.6.13-rc2 that adds securityfs, a virtual
fs that all LSMs can use instead of creating their own. The fs should
be mounted at /sys/kernel/security, and the fs creates that mount point.
This will make the LSB people happy that we aren't creating a new
/my_lsm_fs directory in the root for every different LSM.
It has changed a bit since the last version, thanks to comments from
Mike Waychison.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@osdl.org>
|
|
This patch adds a reqprot parameter to the security_file_mmap and
security_file_mprotect hooks that is the original requested protection
value prior to any modification for read-implies-exec, and changes the
SELinux module to allow a mode of operation (controllable via a
checkreqprot setting) where it applies checks based on that protection
value rather than the protection that will be applied by the kernel,
effectively restoring SELinux's original behavior prior to the introduction
of the read-implies-exec logic in the mainline kernel. The patch also
disables execmem and execmod checking entirely on PPC32, as the PPC32 ELF
ABI presently requires RWE segments per Ulrich Drepper.
At present, the read-implies-exec logic causes SELinux to see every
mmap/mprotect read request by legacy binaries or binaries marked with
PT_GNU_STACK RWE as a read|execute request, which tends to distort policy
even if it reflects what is ultimately possible. The checkreqprot setting
allows one to set the desired behavior for SELinux, so either the current
behavior or the original behavior is possible. The checkreqprot value has
a compile-time configurable default value and can also be set via boot
parameter or at runtime via /selinux/checkreqprot if allowed by policy.
Thanks to Chris Wright, James Morris, and Colin Walters for comments on an
earlier version of the patch.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: James Morris <jmorris@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
This patch series adds SELinux support to reiserfs.
This patch adds an S_PRIVATE flag to inode->i_flags to mark an inode as
filesystem-internal. As such, it should be excepted from the security
infrastructure to allow the filesystem to perform its own access control.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
Acked-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
The following patch splits bprm_apply_creds into two functions,
bprm_apply_creds and bprm_post_apply_creds. The latter is called after the
task_lock has been dropped. Without this patch, SELinux must drop the
task_lock and re-acquire it during apply_creds, making the 'unsafe' flag
meaningless to any later security modules. Please apply.
Signed-off-by: Serge Hallyn <serue@us.ibm.com>
Signed-off-by: Stephen Smalley <sds@epoch.ncsc.mil>
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
The four patches in this series fix deadlocks with quotas of pagelock (the
problem was lock inversion on PageLock and transaction start - quota code
needed to first start a transaction and then write the data which subsequently
needed acquisition of PageLock while the standard ordering - PageLock first
and transaction start later - was used e.g. by pdflush). They implement a
new way of quota access to disk: Every filesystem that would like to implement
quotas now has to provide quota_read() and quota_write() functions. These
functions must obey quota lock ordering (in particular they should not take
PageLock inside a transaction).
The first patch implements the changes in the quota core, the other three
patches implement needed functions in ext2, ext3 and reiserfs. The patch for
reiserfs also fixes several other lock inversion problems (similar as ext3
had) and implements the journaled quota functionality (which comes almost for
free after the locking fixes...).
The quota core patch makes quota support in other filesystems (except XFS
which implements everything on its own ;)) unfunctional (quotaon() will refuse
to turn on quotas on them). When the patches get reasonable wide testing and
it will seem that no major changes will be needed I can make fixes also for
the other filesystems (JFS, UDF, UFS).
This patch:
The patch implements the new way of quota io in the quota core. Every
filesystem wanting to support quotas has to provide functions quota_read()
and quota_write() obeying quota locking rules. As the writes and reads
bypass the pagecache there is some ugly stuff ensuring that userspace can
see all the data after quotaoff() (or Q_SYNC quotactl). In future I plan
to make quota files inaccessible from userspace (with the exception of
quotacheck(8) which will take care about the cache flushing and such stuff
itself) so that this synchronization stuff can be removed...
The rewrite of the quota core. Quota uses the filesystem read() and write()
functions no more to avoid possible deadlocks on PageLock. From now on every
filesystem supporting quotas must provide functions quota_read() and
quota_write() which obey the quota locking rules (e.g. they cannot acquire the
PageLock).
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
With this we're back to the times when changing skbuff.h only triggers
rebuild of _net_ related stuff 8)
This uncovered a bug in rmap.h, that was not including mm.h to get the
definition of struct vm_area_struct, working by luck.
Signed-off-by: Arnaldo Carvalho de Melo <acme@conectiva.com.br>
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Stephen Smalley notes that send_sigurg isn't mediated by LSM in the same
manner as send_sigio. Patch below is a slight modification of Stephen's
original patch. It moves the security_file_send_sigiotask() hook into the
sigio_perm(). The hook's fd and reason arguments are replaced with the
signum. sigio_perm() and it's callers are updated to pass the signum
through to the hook. In send_sigio case, the signum is simply fown->signum
or SIGIO when signum is 0, however in send_sigurg the kernel doesn't use
fown->signum, it always sends SIGURG.
From: Stephen Smalley <sds@epoch.ncsc.mil>
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
.. broken by the rename.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Rename security_scaffolding_startup() to security_init(). It always
bothered me.
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
I have received positive feedback from various individuals who have applied my
BSD Secure Levels LSM patch, and so at this point I am submitting it to you
with a request to merge it in. Nothing has changed in this patch since when I
last posted it to the LKML, so I am not re-sending it there.
This first patch adds hooks to catch attempts to set the system clock back.
Signed-off-by: Michael A. Halcrow <mahalcro@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
This patch replaces the dentry parameter with an inode in the LSM
inode_{set|get|list}security hooks, in keeping with the ext2/ext3 code.
dentries are not needed here.
Signed-off-by: James Morris <jmorris@redhat.com>
Signed-off-by: Stephen Smalley <sds@epoch.ncsc.mil>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
security.h gets pulled in in lots of places, so use forward declarations
for struct ctl_table instead of pulling sysctl in everywhere.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
POSIX specifies that the limit settings provided by getrlimit/setrlimit are
shared by the whole process, not specific to individual threads. This
patch changes the behavior of those calls to comply with POSIX.
I've moved the struct rlimit array from task_struct to signal_struct, as it
has the correct sharing properties. (This reduces kernel memory usage per
thread in multithreaded processes by around 100/200 bytes for 32/64
machines respectively.) I took a fairly minimal approach to the locking
issues with the newly shared struct rlimit array. It turns out that all
the code that is checking limits really just needs to look at one word at a
time (one rlim_cur field, usually). It's only the few places like
getrlimit itself (and fork), that require atomicity in accessing a whole
struct rlimit, so I just used a spin lock for them and no locking for most
of the checks. If it turns out that readers of struct rlimit need more
atomicity where they are now cheap, or less overhead where they are now
atomic (e.g. fork), then seqcount is certainly the right thing to use for
them instead of readers using the spin lock. Though it's in signal_struct,
I didn't use siglock since the access to rlimits never needs to disable
irqs and doesn't overlap with other siglock uses. Instead of adding
something new, I overloaded task_lock(task->group_leader) for this; it is
used for other things that are not likely to happen simultaneously with
limit tweaking. To me that seems preferable to adding a word, but it would
be trivial (and arguably cleaner) to add a separate lock for these users
(or e.g. just use seqlock, which adds two words but is optimal for readers).
Most of the changes here are just the trivial s/->rlim/->signal->rlim/.
I stumbled across what must be a long-standing bug, in reparent_to_init.
It does:
memcpy(current->rlim, init_task.rlim, sizeof(*(current->rlim)));
when surely it was intended to be:
memcpy(current->rlim, init_task.rlim, sizeof(current->rlim));
As rlim is an array, the * in the sizeof expression gets the size of the
first element, so this just changes the first limit (RLIMIT_CPU). This is
for kernel threads, where it's clear that resetting all the rlimits is what
you want. With that fixed, the setting of RLIMIT_FSIZE in nfsd is
superfluous since it will now already have been reset to RLIM_INFINITY.
The other subtlety is removing:
tsk->rlim[RLIMIT_CPU].rlim_cur = RLIM_INFINITY;
in exit_notify, which was to avoid a race signalling during self-reaping
exit. As the limit is now shared, a dying thread should not change it for
others. Instead, I avoid that race by checking current->state before the
RLIMIT_CPU check. (Adding one new conditional in that path is now required
one way or another, since if not for this check there would also be a new
race with self-reaping exit later on clearing current->signal that would
have to be checked for.)
The one loose end left by this patch is with process accounting.
do_acct_process temporarily resets the RLIMIT_FSIZE limit while writing the
accounting record. I left this as it was, but it is now changing a limit
that might be shared by other threads still running. I left this in a
dubious state because it seems to me that processing accounting may already
be more generally a dubious state when it comes to NPTL threads. I would
think you would want one record per process, with aggregate data about all
threads that ever lived in it, not a separate record for each thread.
I don't use process accounting myself, but if anyone is interested in
testing it out I could provide a patch to change it this way.
One final note, this is not 100% to POSIX compliance in regards to rlimits.
POSIX specifies that RLIMIT_CPU refers to a whole process in aggregate, not
to each individual thread. I will provide patches later on to achieve that
change, assuming this patch goes in first.
Signed-off-by: Roland McGrath <roland@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Modifies the LSM netlink_send() hook so that it takes a struct sock
parameter. SELinux will use this parameter to lookup the class of socket,
which was assigned during socket security initialization.
Signed-off-by: James Morris <jmorris@redhat.com>
Signed-off-by: David S. Miller <davem@redhat.com>
|
|
Add proper __user annotation for shm_shmat hook in security.h.
From: Mika Kukkonen <mika@osdl.org>
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Under SELinux, and potentially other LSMs, we need to be able to
distinguish between user sockets and kernel sockets. For SELinux
specifically, kernel sockets need to be specially labeled during creation,
then bypass access control checks (they are controlled by the kernel
itself and not subject to SELinux mediation).
This addresses a class of potential issues in SELinux where, for example,
a TCP NFS session times out, then the kernel re-establishes an RPC
connection upon further user activity. We do not want such kernel
created sockets to be labeled with user security contexts.
sock_create() and sock_create_kern() are wrapper functions, which seems
semantically clearer to me than e.g. adding a flag to sock_create(). If
you prefer the latter, then let me know.
The patch also adds an argument to the LSM socket creation functions
indicating whether the socket being created is a kernel socket or not.
|
|
From: Chris Wright <chrisw@osdl.org>
Contributions from:
Stephen Smalley <sds@epoch.ncsc.mil>
Andy Lutomirski <luto@stanford.edu>
During exec the LSM bprm_apply_creds() hooks may tranisition the program to a
new security context (like setuid binaries). The security context of the new
task is dependent on state such as if the task is being ptraced.
ptrace_detach() doesn't take the task_lock() when clearing task->ptrace. So
there is a race possible where a process starts off being ptraced, the
malicious ptracer detaches and if any checks agains task->ptrace are done more
than once, the results are indeterminate.
This patch ensures task_lock() is held while bprm_apply_creds() hooks are
called, keeping it safe against ptrace_attach() races. Additionally, tests
against task->ptrace (and ->fs->count, ->files->count and ->sighand->count all
of which signify potential unsafe resource sharing during a security context
transition) are done only once the results are passed down to hooks, making it
safe against ptrace_detach() races.
Additionally:
- s/must_must_not_trace_exec/unsafe_exec/
- move unsafe_exec() call above security_bprm_apply_creds() call rather than
in call for readability.
- fix dummy hook to honor the case where root is ptracing
- couple minor formatting/spelling fixes
|
|
From: Andy Lutomirski <luto@myrealbox.com>
Fixes from me, Olaf Dietsche <olaf+list.linux-kernel@olafdietsche.de>
In fs/exec.c, compute_creds does:
task_lock(current);
if (bprm->e_uid != current->uid || bprm->e_gid != current->gid) {
current->mm->dumpable = 0;
if (must_not_trace_exec(current)
|| atomic_read(¤t->fs->count) > 1
|| atomic_read(¤t->files->count) > 1
|| atomic_read(¤t->sighand->count) > 1) {
if(!capable(CAP_SETUID)) {
bprm->e_uid = current->uid;
bprm->e_gid = current->gid;
}
}
}
current->suid = current->euid = current->fsuid = bprm->e_uid;
current->sgid = current->egid = current->fsgid = bprm->e_gid;
task_unlock(current);
security_bprm_compute_creds(bprm);
I assume the task_lock is to prevent another process (on SMP or preempt)
from ptracing the execing process between the check and the assignment. If
that's the concern then the fact that the lock is dropped before the call
to security_brpm_compute_creds means that, if security_bprm_compute_creds
does anything interesting, there's a race.
For my (nearly complete) caps patch, I obviously need to fix this. But I
think it may be exploitable now. Suppose there are two processes, A (the
malicious code) and B (which uses exec). B starts out unprivileged (A and
B have, e.g., uid and euid = 500).
1. A ptraces B.
2. B calls exec on some setuid-root program.
3. in cap_bprm_set_security, B sets bprm->cap_permitted to the full
set.
4. B gets to compute_creds in exec.c, calls task_lock, and does not
change its uid.
5. B calls task_unlock.
6. A detaches from B (on preempt or SMP).
7. B gets to task_lock in cap_bprm_compute_creds, changes its
capabilities, and returns from compute_creds into load_elf_binary.
8. load_elf_binary calls create_elf_tables (line 852 in 2.6.5-mm1),
which calls cap_bprm_secureexec (through LSM), which returns false (!).
9. exec finishes.
The setuid program is now running with uid=euid=500 but full permitted
capabilities. There are two (or three) ways to effectively get local root
now:
1. IIRC, linux 2.4 doesn't check capabilities in ptrace, so A could
just ptrace B again.
2. LD_PRELOAD.
3. There are probably programs that will misbehave on their own under
these circumstances.
Is there some reason why this is not doable?
The patch renames bprm_compute_creds to bprm_apply_creds and moves all uid
logic into the hook, where the test and the resulting modification can both
happen under task_lock().
This way, out-of-tree LSMs will fail to compile instead of malfunctioning.
It should also make life easier for LSMs and will certainly make it easier
for me to finish the cap patch.
|
|
From: James Morris <jmorris@redhat.com>
selinux is currently inspecting the filesystem name ("nfs" vs "coda" vs
watever) to work out whether it needs to hanbdle binary mount data.
Eliminate all that by adding a flag to file_system_type.fs_flags.
|
|
From: Tim Hockin <thockin@sun.com>,
Neil Brown <neilb@cse.unsw.edu.au>,
me
New groups infrastructure. task->groups and task->ngroups are replaced by
task->group_info. Group)info is a refcounted, dynamic struct with an array
of pages. This allows for large numbers of groups. The current limit of
32 groups has been raised to 64k groups. It can be raised more by changing
the NGROUPS_MAX constant in limits.h
|
|
From: James Morris <jmorris@redhat.com>
This series of patches adds support for SELinux 'context mounts', which
allows filesystems to be assigned security context information at mount time.
For example, some filesystems do not support extended attributes (e.g. NFS,
vfat), and this feature allows security contexts to be assigned to them on a
per-mountpoint basis. It is also useful when the existing labeling on a
filesystem is untrusted or unwanted for some reason (e.g. removable media),
and needs to be overridden with a safe default.
The first patch below consists of infrastructure changes to the kernel:
- A new LSM hook has been added, sb_copy_data, which allows the security
module to copy security-specific mount data once the superblock has been
setup by the filesystem.
- The sb_kern_mount hook has been modified to take this security data as a
parameter, and would typically be used at that point to configure the
security parameters of the filesystem being mounted.
- Allocation and freeing of the security data has been implemented in the
core fs code as it is cleaner than trying to do it purely via LSM hooks,
and should make maintenance easier. This code will be compiled away if LSM
is not enabled.
|
|
From: Chris Wright <chrisw@osdl.org>
Add default hooks for both the dummy and capability code to protect the
XATTR_SECURITY_PREFIX namespace. These EAs were fully accessible to
unauthorized users, so a user that rebooted from an SELinux kernel to a
default kernel would leave those critical EAs unprotected.
(Acked by Stephen Smalley)
|
|
From: James Morris <jmorris@redhat.com>
This patch adds a new option for Unix sockets, SO_PEERSEC, and an
associated LSM hook, getpeersec. The SELinux handler is also included.
The purpose of this is to allow applications to obtain each others security
credentials, analagously to the existing SO_PEERCRED option.
Examples of use are Security Enhanced D-BUS and Security Enhanced X.
This patch was previously approved in principle by David, and has been
updated with feedback from Chris Wright and extended to cover all
architectures.
|
|
From: Stephen Smalley <sds@epoch.ncsc.mil>
This patch changes the security_inode_permission hook to also take a
nameidata parameter in addition to the existing inode and mask parameters.
A nameidata is already passed (although sometimes NULL) to
fs/namei.c:permission(), and the patch changes exec_permission_lite() to
also take a nameidata parameter so that it can pass it along to the
security hook.
The patch includes corresponding changes to the SELinux module to use the
nameidata information when it is available; this allows SELinux to include
pathname information in audit messages when a nameidata structure was
supplied.
|
|
From: Stephen Smalley <sds@epoch.ncsc.mil>
This patch against 2.5.73 replaces vm_enough_memory with a security hook
per Alan Cox's suggestion so that security modules can completely replace
the logic if desired.
Note that the patch changes the interface to follow the convention of the
other security hooks, i.e. return 0 if ok or -errno on failure (-ENOMEM in
this case) rather than returning a boolean. It also exports various
variables and functions required for the vm_enough_memory logic.
|
|
From: Stephen Smalley <sds@epoch.ncsc.mil>
This patch adds an AT_SECURE auxv entry to pass a boolean flag indicating
whether "secure mode" should be enabled (i.e. sanitize the environment,
initial descriptors, etc) and allows each security module to specify the
flag value via a new hook.
New userland can then simply obey this flag when present rather than
applying other methods of deciding (sample patch for glibc-2.3.2 can be
found at http://www.cs.utah.edu/~sds/glibc-secureexec.patch).
This change enables security modules like SELinux to request secure mode
upon changes to other security attributes (e.g. capabilities,
roles/domains, etc) in addition to uid/gid changes or even to completely
override the legacy logic.
The legacy decision algorithm is preserved in the default hook functions
for the dummy and capability security modules.
Credit for the idea of adding an AT_SECURE auxv entry goes to Roland
McGrath.
|
|
|
|
The task_kmod_set_label hook is no longer necessary.
kmod is now handled by keventd which already does reparent_to_init, so
there is no need to worry about getting the security labels right for
code running off the keventd workqueue.
|
|
From: Stephen Smalley <sds@epoch.ncsc.mil>
This patch against 2.5.69-bk adds an xattr handler for security labels
to devpts and corresponding hooks to the LSM API to support conversion
between xattr values and the security labels stored in the inode
security field by the security module.
This allows userspace to get and set the security labels on devpts
nodes, e.g. so that sshd can set the security label for the pty using
setxattr, just as sshd already sets the ownership using chown.
SELinux uses this support to protect the pty in accordance with the user
process' security label. The changes to the LSM API are general and
should be re-useable by xattr handlers in other pseudo filesystems to
support similar security labeling. The xattr handler for devpts
includes the same generic framework as in ext[23], so handlers for other
kinds of attributes can be added easily in the future.
|
|
From: Stephen Smalley <sds@epoch.ncsc.mil>
This patch against 2.5.69-bk adds a hook to proc_pid_make_inode to allow
security modules to set the security attributes on /proc/pid inodes based on
the security attributes of the associated task. This is required by SELinux
in order to control access to the process state accessible via /proc/pid
inodes in accordance with the task's security label.
An alternative approach that was considered was to implement an xattr handler
for /proc/pid inodes. That approach would still require a hook call from the
xattr handler to the security module to obtain an xattr value based on the
task security attributes, so it would add a further level of
indirection/translation. The only benefit of implementing an xattr handler
for the /proc/pid inodes would be that the /proc/pid inode security labels
could then be exported to userspace. However, the /proc/pid inode security
labels are only used internally by the security module for access control
purposes, and userspace access to the full range of process attributes is
already provided via the /proc/pid/attr interface. Consequently, a simple
hook in proc_pid_make_inode seemed preferable.
|
|
From: Stephen Smalley <sds@epoch.ncsc.mil>
This updated patch against 2.5.69 merges the readdir and lookup routines
for proc_base and proc_attr, fixes the copy_to_user call in proc_attr_read
and proc_info_read, moves the new data and code within CONFIG_SECURITY, and
uses ARRAY_SIZE, per the comments from Al Viro and Andrew Morton. As
before, this patch implements a process attribute API for security modules
via a set of nodes in a /proc/pid/attr directory. Credit for the idea of
implementing this API via /proc/pid/attr nodes goes to Al Viro. Jan Harkes
provided a nice cleanup of the implementation to reduce the code bloat.
|
|
|
|
From: Stephen Smalley <sds@epoch.ncsc.mil>
This patch against 2.5.69 adds a security_inode_post_setxattr hook so that
security modules can update the inode security structure after a successful
setxattr, and it moves the existing security_inode_setxattr hook call after
the taking the inode semaphore so that atomicity is provided for the
security check and the update to the inode security structure.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This patch adds the LSM security_syslog hook for controlling the
syslog(2) interface relative to 2.5.59 plus the previously posted
security_sysctl patch. In response to earlier comments by Christoph,
the existing capability check for syslog(2) is moved into the
capability security module hook function, and a corresponding dummy
security module hook function is defined that provides traditional
superuser behavior. The LSM hook is placed in do_syslog rather than
sys_syslog so that it is called when either the system call interface
or the /proc/kmsg interface is used. SELinux uses this hook to
control access to the kernel message ring and to the console log
level.
|
|
This patch adds a LSM sysctl hook for controlling access to
sysctl variables to 2.5.59, split out from the lsm-2.5 BitKeeper tree.
SELinux uses this hook to control such accesses in accordance with the
security policy configuration.
|
|
This patch removes the security_inode_post_lookup hook entirely and
adds a security_d_instantiate hook call to the d_instantiate function
and the d_splice_alias function. The inode_post_lookup hook was
subject to races since the inode is already accessible through the
dcache before it is called, didn't handle filesystems that directly
populate the dcache, and wasn't always called in the desired context
(e.g. for pipe, shmem, and devpts inodes). The d_instantiate hook
enables initialization of the inode security information. This hook
is used by SELinux and by DTE to setup the inode security state, and
eliminated the need for the inode_precondition function in SELinux.
|