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)
On Fri, 9 Apr 1999, Theodore Y. Ts'o wrote:

> 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....

OK, but if you're running a kernel that doesn't understand this hack, how
do you give a process only the ability to listen on low ports? In the
absence of the 'cap flag'=setuid 0, old inheritance behavior will still
apply; with this hack and a non-setuid binary, the permitted and
inheritable parts can still be used. (ref my ideas in 'caps in elf next
(final?) itteration')

> 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.

Eh, it would just fall back on the crummy older behavior. Without 'setuid
0' it would have _no_ privs, with it set it would get all...

> 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....

Well, sure, that's a bit ugly; I just feel that the benefits outweigh the
drawbacks.

>
> - Ted
>

- --
David L. Parsley
Network Specialist
City of Salem Schools


-
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.094 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site