lkml.org 
[lkml]   [1999]   [Jul]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subject[RFC] new kernel syscall

Hi,

I want to make a new kernel syscall. Obviously, before doing the (trivial)
work, I want to check it is considered a good idea.

The syscall essentially exposes current->dumpable to userland. NAMES FOR
THE SYSCALL ON A POSTCARD PLEASE.

Why would you want do do this?

Well, in userland, we are having to do a lot of second guessing of
current->dumpable. If dumpable is FALSE, we need to restrict several
things in the dynamic linker, and libc, for security reasons.

The new capabilities will gain fs support soon and suddenly we will have
privileged binaries with euid = ruid, egid = rgid, but capabilities still
raised! To glibc this doesn't look privileged even though it is =>
LD_PRELOAD security hole. Anoungst others.

So by exposing isdumpable() or similar we can move convoluted userland
logic like this into the kernel where it should be (and already exists).
As an added bonus we save 3 syscalls per program launch :-) [getuid()
geteuid() getgid() getegid() -> isdumpable()]

Better still the same syscall can expose the ability for a process to
_set_ its dumpable flag. A process would be allowed to always clear its
dumpable flag but never set it. This is a very useful security tool
because a daemon running as e.g. "gdm" can clear current->dumpable and
then a breach of a different "gdm" sibling process finds itself unable to
attach to its sibling and snoop passwords.

...

Comments please? A worthy 2.3 item?

Chris


-
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:53    [W:1.092 / U:0.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site