> I know how to write a security monitor that does what you want:
> use ptrace. (Yeah, I know, ptrace is my one-trick pony.)
[snip]
> So I think that this architecture:
> (1) can be made to work today in user space
> (2) keeps all the complicated rules in user space
> (3) enables logging with logging mechanisms in user space
> (4) with a simple mechanism-only kernel patch, this architecture
> can run about as fast as any possible solution that keeps
> the complicated rules in user space
(5) has already been implemented, very much like you describe,
and a)works, b)is fairly flexible, and c)yields decent
performance.
At the Usenix Security Symposium some months ago in DC, a project was
presented which uses syscall hooks (using ptrace and/or a kernel module to
overload; I can't recall which was their current model, and which was their
future plan) to enforce policy. (This will sound somewhat like Janus or
SeOS, for those who remember them ;)
The interesting thing was the flexibility: their architecture understood
"process X may make syscall foo, but only after making bar and not having
made yada; after making syscall foo, the only syscall allowed is zed." So
you can (and they had) develop specs for say an anon ftp server, which is
allowed to setuid back to root but then may _only_ bind to port 20 before
dropping privs again, force httpd to open(2) only fixed file paths, etc.
Overhead for performing ftp service or web service in such an environment
was measured to be between 3 and 5 percent (overall; the actual per-syscall
overhead was of course higher).
Their goal was not to be Linux-specific, but Linux was their only working
implementation at the time the paper was presented. Unfortunately the
professor whose project it was was moving to another university, didn't
have a new website set up yet, etc. I can't remember off the top of my
head where he was moving to, but I have it scribbled on some notes
somewhere ;) Perhaps someone else who was at USS was at the same talk and
remembers more? The brief blurb about the talk is available at:
http://www.usenix.org/publications/library/proceedings/sec99/sekar.html
I think I'll go dig up the old address of the author and give it a shot...
-- Hank Leininger <hlein@progressive-comp.com>- 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/