begin quoting Gabriel Sechan as of Mon, Mar 14, 2005 at 12:51:04AM -0600:
>
>
> >From: Stewart Stremler <[EMAIL PROTECTED]
> >Don't understand the consequences of executable attachements? Say no,
> >and have the software strip 'em out. Don't understand the consequences
> >of running Network Services? Say no, and don't enable 'em on the system.
> >Don't understand the tradeoffs and risks of Javascript? Disable it.
>
> But then they wouldn't be able to see that new awesome website that
> requires javascript 9.1 and flash 15.8 and 3 new plugins. You don't really
> expect them to give up that, do you?
This is why I sometimes wonder if it's a bad thing to criminalize
viruses and trojans. To keep the cyber-immune system strong, it needs
to be continually tested.
But then, I wonder if perhaps it wouldn't be nicer to criminalize being
*infected* and not Taking Steps once you're informed about the event. . .
> >Malice cannot always be detected. It depends on _intent_, and there's
> >no way of getting that into the system.
>
> Don't you always set your evil bit?
Whoops! Nope. That's what I get for not using a constant...
#define EVIL 1
> >What we need is an efficient way of sandboxing processes. Because
> >programs can often test their environment to see if they've been
> >given the sort of control that the programmers desire, we need to
> >have the sandbox be *transparent*.
>
> What we really need are more fine grained permissions. Right now, all we
> have is root/not root. All or nothing.
Well, we have a *little* more than that.
We have groups and file permissions. And in UNIX, Everything Is A File.
> What really needs to be done is to
> allow file IO, network IO (of all different types- TCP, UDP, listen(), and
> connect() by port), execute, etc to be set separately. So you can set
On a per-process basis, presumably.
> Apache to allow incoming connections on port 80 and read from /http, but
> not allow it to execute a program.
find / -type f -exec chmod o-x {} \;
Only those programs owned by a group that the apache process is a member of,
and have g+rx, can be executed.
However, group-management would get a little complicated, I think.
> All programs start with minimum
> permissions, and the OS querries the user for more if needed. Ideally
> permission sets could be saved so you can start a program with pre-arranged
> privlidges each time. Oh, and normal users could not grant additional
> privlidges beyond read/write in their own home.
But could restrict them, I hope.
Still -- that doesn't keep the programmers from coding in "I want write
permission to /usr, and if I don't get it, I'm going to exit right now."
-Stewart "Replace creat, open, close, link, unlink, mknod, and fcntl?" Stremler
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
