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 headers: use the sticky bit!
On Sat, 10 Apr 1999, David L. Parsley (lkml account) wrote:

> Hi all,
> Geez, instead of overloading the meaning of 'setuid 0', let's just
> use the sticky bit! I.e., sticky bit==cap flag:
>
If the capabilities are present we should use them.
It is _redundant_ and unnecessary to have seperate flags
for the existence of capabilities and the capabilities
themselves.

In fact, I think that _all_ binaries should have capabilities
specified. If a binary is not SUID and you try to run it
without sufficient caps/privs yourself you should get an appropriate
error and your prompt back.

One in, all in.

> - To set the cap flag, a user (process) needs CAP_SETFCAP raised, and the
> kernel (besides the normal fs checks) validates the cap headers as well
> for legality. (this also applies to creating files with this flag raised;
> i.e., through a copy operation)

So we have a capability (to set capabilities) assigned to the UID.
WHAT did you think I have been talking about all this time?

> - While the cap flag is set, the file is immutable, so the file owner
> can't edit the file directly to raise caps.

The file owner cannot set any caps he does not possess anyway
so this is not a problem.

> - A file that is both setuid root and capability enabled has only those
> capabilities granted in conjuction w/ the headers; if it's only setuid
> root, the kernel can (as a configurable option?) treat it as before and
> raise all caps.
>
Right, but why should this just apply to root? I thought that we were
trying to do away with the need for root on a production system
here, and all of the ideas being presented still depend on
direct action by root for all changes in capabilities.

Am I the only one here who sees a problem with this?!

> This can bring us _really_ close to true capabilities support,
> while avoiding the ugly hack of also storing uid + suid bit in the elf
> headers.
>
That would be, and is, an ugly hack.
It is also, I'll type this slowly, completely unnecessary!

Ownership of the file is stored in the filesystem.
If the filesystem says the binary is SUID-joe, then it may
not do anything that joe may not do were he logged in.

If joe tried to create a binary that could connect to port-23,
and joe did not have the privilege/capability to connect to port-23
himself, he should fail.

I like the idea of perhaps _managing_ caps through a sudo-type
program, but the caps and privs _must_ be inherent to each and
every user on the system or there is not much point to the whole
exercise.

> thoughts?
>
Oh, you know it.

Daniel Taylor [gotta get a .sig file one o' these days]


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