Friendly and Secure Desktop Operating System
tss at iki.fi
Tue Oct 28 12:52:42 PST 2003
On Tue, 2003-10-28 at 21:29, Johnson David wrote:
> On Tuesday 28 October 2003 07:33 am, Daniela wrote:
> > Found this link today, I thought it might be an interesting thing to
> > discuss: http://irccrew.org/~cras/security/friendly-secure-os.html
> "Disclaimer: I haven't done any research on this area."
> Oh wonderful! This guy doesn't even know the problem domain, yet he's
> throwing out solutions.
That mostly means that I haven't tried to find existing similiar papers
or designs. It doesn't mean I don't know anything about it.
That page is mostly just a few thoughts on the subject, enough to get
other people understand the idea (which seems to have failed) and get
interested enough about implementing it. I believe I would be capable of
fully designing and implementing it myself, but I just don't have time.
> Here's a classic mis-assumption of his: "What you'd need to be able to
> run any software securely is to run it in a complete sandbox." Although
> this isn't a bad idea, is completely ignores a whole class of security
> issues, namely, denial of service.
Well .. I don't actually believe DoS to be much of a security problem in
desktop systems. If everything else fails, you reboot the computer. So
what? While you're doing something important, don't go running random
Of course it's better to try to prevent them, but I don't think it's
really possible without getting on the way of user. Sure, you could say
that processes by default shouldn't eat more than 100MB of memory, but
what happens when you're modifying a huge document and want to save it
and process goes over the 100MB limit? You'll kill the word processor
and lose your changes? fork() limit would be somewhat more reasonable,
but that could be problematic too.
Anyway, in my started rewrite of the document I did include a bit better
Operating system MUST prevent malicious software from:
- Modifying or erasing sensitive data
- Transferring sensitive data out of your system
- Affecting other software in any way
Operating system SHOULD TRY to prevent malicious software from:
- Using your system as a proxy to send attacks
- Using your processing power or other resources for unintended purposes
I don't believe there's any simple universal solution for the last two.
- Privilege separation
- Using minimal required privileges
- Making it difficult for user to shoot himself in foot by making it clear
when he's doing potentially harmful things
- Designing the system in a way that security warnings are a rarely occuring
exception and user is actually required to pay some attention to them.
- Make it clear when software is running to detect software that tries to
leave itself running in background and consume your system resources
after the visible part of it is gone.
> Here's another: "Word Processors... No privileges needed." Those who
> ignore the lessons of history are doomed to repeat them.
Oh? What privileges does it need then? My idea of a word processor is
that it should be able to read and write document files with it, nothing
else. I already described the open/save file service for that.
> And a really bad one from his discussion: "Also note that I believe it
> would be possible to implement this in relatively short time on top of
> some existing UNIX system and maybe KDE or GNOME as the user
> interface." Security is not something that gets slapped on as an
If you design the base secure, you should be able to run anything on top
of it securely. Kernel and windowing system changes are critical. The
base user interface is also critical to get working right. The actual
applications that are run can be the same old ones since it's the kernel
and windowing system that forces them to behave nicely.
> I would very like to see how he would rewrite his article after doing
> some research in this area.
Like I said, I don't have time. I just wanted to give a few ideas to
other people and hope they'd implement it.
Of course, if I got actually paid to do that, I would suddenly have
enough time :)
More information about the freebsd-advocacy