lkml.org 
[lkml]   [1999]   [Apr]   [10]   [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 Sat, 10 Apr 1999, Steffen Zahn wrote:

> >>>>> "David" == David L Parsley (lkml account) <kparse@salem.k12.va.us> writes:
>
> David> With cap support directly in the FS, it won't work across NFS,
> David> or after a cp, tar, cpio, what have you without modifying all
> David> these tools. It also won't work on any other fs without cap
> David> support. (of course) This solution has the nice property of
> David> working _now_, (well, pending code obviously) and having great
> David> compatibility with current Linux code.
>
> The content of executable files never carried around special
> privileges in Unix, they are always stored in metadata. And never
> are such privileges carelessly copied around.

Well, when I 'cp sendmail' as root, the resulting binary is setuit root.
Maybe you misunderstand the idea: current fs's & tools don't support the
notion of per-file capabilities, but they _do_ support the notion of
'setuid 0' which traditionally made a binary 'all-powerful'. With this
scheme, we redefine the notion of 'setuid 0' to mean that a binary has
some cap's raised, and stored in the elf headers.

The problem is, to get good semantics, there are a lot of repercussions
which all need to be thought out. For instance, I now find that besides
needing to store the true owner of the file in the headers, we also need
to store the true value of the setuid bit, to determine whether the file
actually executes as the owner or not. (group info is _not_ needed)

> Transfer of
> privileges needs careful considerations and itself special
> privileges. For example even if you can read /bin/login as a
> normal user you can not copy its privilege with the file
> content.

The same should definitely apply here; though if the user has capA & capB
raised, the file should be allowed those. (this is why the actuall coding
get's deep quick)

> The only reasonable approach is that all tools and
> transfer protocols, that are not aware of capabilities, erase all
> capabilities by default. This means that default behavior of
> system calls (open,creat etc.) has to be set accordingly. This
> also means that transfer protocols (NFS), that are not aware of
> capabilities, do not transfer capabilities.

Currently the notion of 'setuid root' propagates all over _anyway_ if root
is copying the file. This just puts a finer grain on the propagation of
capabilities.


> Best regards
> Steffen Zahn
>
> --
> home email: user@domain where domain=berlin.snafu.de, user=zahn
> Use of my address for unsolicited commercial advertising is forbidden.
> 2^3021377 - 1 | "Where do you want to crash today?"
>

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