lkml.org 
[lkml]   [1998]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: ActiveWhy (was Re: Comments on Microsoft Open Source document)
Date
From
Pete Chown writes:
> This gives us something like ActiveX but portable across platforms. Now
> we need security... Firstly it must be understood that unlike ActiveX
> and Java controls, ActiveWhy controls will always run in a separate
> process context. Under Linux, there will be a kernel module which will
> implement a new personality. This personality will deny the control
> access to any system calls which might be used to compromise security.
> Instead the control must perform all I/O through a pipe linked to the
> browser. The browser can then decide (using a scheme like Netscape's
> SecurityManager) whether to allow or deny a request.

I did a proof-of-concept thing like a year or two ago which I called
"supervisor". I seem to recall others had similar ideas. Rather than
use a pipe to communicate, a supervisor daemon listened on a Unix
domain socket. When the sand-box process ran, it did so with a preload
library which intercepted calls to open(), socket(), connect(),
unlink(), rename() and so on. It sent the arguments and any file
descriptors to the supervisor which received them and, after vetting,
carried out the appropriate operation on behalf of the sand-box
process. Operations like read() and write() on already-open file
descriptors were real system calls without proxying.

The kernel side (which I didn't get round to doing) is the simple
part, bar one glitch: just return -ENOSYS for open(), socket() and so
on in such processes and make that behaviour inherit across fork.
The glitch is that Linux uses a single syscall (SYS_socketcall) to
multiplex all socket calls such as socket(), connect(), sendto(),
recvmsg() and so on, some of which need to return -ENOSYS and some of
which need to run as normal. That means you can't use the obvious
generic way of handling things which would be per-process bitmap of
allowed system calls which is inherited across fork and a system call
which allows an unprivileged process to set bits in the mask
(meaning disable them) but not reset them. Now that capabilities are
in 2.1, they could be used instead but it means hacking more different
parts of the kernel than just a generic bitmap checked on each syscall
entry. The overhead of (the entry.S assembler equivalent of)
if (current->bitmap && current->bitmap[sysnum])
return -ENOSYS; /* or -EACCES or -EPERM */
would probably still upset some people.

--Malcolm

--
Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Unix Systems Programmer
Oxford University Computing Services

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