lkml.org 
[lkml]   [1998]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectpure capabilities support (Was: more capability ..)
[COMPLETELY OFFTOPIC PLUG: I'm trying to arrange to get to linux
expo. If anybody is interested in sharing rooms or is driving from
Washington D.C (that's probably where my plane will land), please
contact me. ]


On Sun, Apr 26, 1998 at 01:27:11AM +0200, Andrej Presern wrote:
>
> I know that requests for massive changes of the kernel won't even be
> considered and I wouldn't even think of proposing the idea if I didn't
> think that massive changes are actually not required to at least
> minimally support pure capabilities.
>
> The path that I would propose is to add minimal support. Currently,
> processes can assume that they can call every non privileged system call
> - those that the process actually needs and those that the process
> doesn't need also. To get the ball rolling, I would propose a
> modification of this mechanism, so that a process is able to restrict
> itself to only a subset of system calls, thus throwing away the
> superfluous authority that can be abused if the program contains a bug.
>
> An example use of such a basic and primitive extension would be that a
> suid program can throw away its authority to execve() system call, if it
> doesn't need it. This alone would make it quite difficult for the hacker
> to produce a root shell by means of stack smashing for example, and
> would make it difficult to do so for all time, not just until the next
> bug in argument handling code (of the program or libraries) is found. If
> the program would actually need such authority, it can get a copy of the
> existing capability (which is all syscalls by default for beginning),
> modify it so that it drops execve() and then use one of the two
> capabilities as appropriate in sections where execve() is needed and
> where execve() is not needed, thus restricting the amount of risky code
> arbitrarily (the application can install the with_execve() capability
> just before execve() is called and install without_execve() capability
> where processing user arguments for example).
>

Removing system calls is _not_ the way to go. A system call might seem
to be a nice granularity, but in a real system, it doesn't give you
the granularity needed. For example, you won't be able to make a
distinction between opening immutable, ttys, devices or normal
files. You don't have _any_ way of blocking individual ioctl
calls. You can't make a distinction between different types of
sockets. The POSIX capability patch can do that right now. The system
call table is something we can't change and as it currently stands,
and unless it is drastically changed, it is almost completely useless
to use as a basis to improve security.

Also, for the administrator, it is quite useless as he shouldn't need
complete understanding of the kernel to assign capabilities. POSIX
capabilities make _a lot_ more sense, and not only to the
administrator.

File system support would be operating-system specific. Your
capabilities couldn't be used in a network filesystem without the
different OSes having 'linux-emulation'.

What you probably need to do, is the same you need to do to implement
auditing in the kernel: For each _operation_ done by the kernel, call
some function/macro passing all relevant arguments needed to make a
decision/log the event. Prove me wrong, but I think that's _at least_
what you need to do. It is a huge change.

[...]
>
> Of course, because Linux is not a pure capability system by default,
> such an extension would have some impact on the system. If we don't want
> to make it so that the process has to pass the syscall capability at
> call time, the change to IDT (or the system call table or the
> system_call function) would need to be made at process switch time. The
> other impact would be in the use of kernel memory, because every
> different syscall capability would require some storage. Although only a
> few running tasks would want to have a modified syscall table, such
> tasks would eat up a few hundred extra bytes of non swappable memory for
> their private syscall table which would impact all running programs.
>
> On the other hand, POSIX capabilities also take up extra space. They do
> so with programs residing on the disk, and they do so with running
> tasks, the difference with pure capabilities being that pure
> capabilities only take up space if they are given to an object while
> POSIX capabilities do so always.
>

12 bytes/task. I think you'll have a hard time showing that pure
capabilities are more space efficient than that.

[...]
>
> So, for a slow start, I would like to see these pure capabilities in the
> system:
> 1) create a duplicate of current sys_call_table and return it to me
> 2) disable a syscall in the current sys_call_table
> 3) install a sys_call_table
>

I don't think this is useful, given my arguments above. It strengthens
my belief that pure capabilities still is at the design stage, while
POSIX capabilities is not.

astor

--
Alexander Kjeldaas, Guardian Networks AS, Trondheim, Norway
http://www.guardian.no/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

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