| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
|
|
Hi again,
Still doing my compile, and got this:
CC [M] security/root_plug.o
security/root_plug.c:39: warning: missing initializer
security/root_plug.c:39: warning: (near initialization for `__parm_vendor_id.addr')
security/root_plug.c:42: warning: missing initializer
security/root_plug.c:42: warning: (near initialization for `__parm_product_id.addr')
security/root_plug.c:48: warning: missing initializer
security/root_plug.c:48: warning: (near initialization for `__parm_debug.addr')
Simply upgrading root_plug to use the new module parameter syntax seemed to do
the trick. I made the debug writable, the others just readable to root.
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
|
|
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.
|
|
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.
|
|
As discussed before, this allows for early initialization of security
modules when compiled statically into the kernel. The standard
do_initcalls is too late for complete coverage of all filesystems and
threads, for example.
|
|
Also fixed compiler warnings about the dbg() function.
|
|
|
|
|
