lkml.org 
[lkml]   [1999]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: caps in elf, next itteration (the hack get's bigger)
   Date: 	Fri, 9 Apr 1999 17:48:14 -0400 (EDT)
From: "David L. Parsley (lkml account)" <kparse@salem.k12.va.us>

5) when the kernel exec's an elf binary, the effect is exactly as in my
previous itteration:
- checks capability flag (setuid 0) and if set uses caps + uid + gid from
elf headers
- if calling process has no caps, process runs with no caps
- if calling process has elevated caps, kernel applies the permittable and
inheritable cap flags from the binary (which can only be modified by the
owner in any event)

Note that this means that if you boot a kernel which doesn't know about
this scheme (i.e. a 2.2 or a 2.0 kernel), then a binary which was
intended to have one relatively harmless capability (such as the ability
to bind ports below 1024, for example) and be setuid nobody, would be
interpreted by a kernel which didn't understand capabilities as being
setuid root. This is bad....

The only way to solve this is to have the kernel, when you set any
capabilities using this scheme, mutate some other portion of the ELF
header so that a kernel that doesn't understand this new format will
refuse to run the binary.

The prospect of having the kernel having the capability to read *and*
modify ELF sections still does bother me as putting way to much
complexity into the kernel, though. Especially the prospect of adding a
new ELF section --- that's really not something you want to do in kernel
mode....

- Ted

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.988 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site