Date: Tue, 28 Oct 2003 22:52:39 +0200 From: Timo Sirainen <tss@iki.fi> To: Johnson David <DavidJohnson@Siemens.com> Cc: advocacy@freebsd.org Subject: Re: Friendly and Secure Desktop Operating System Message-ID: <1067374359.15026.126.camel@hurina> In-Reply-To: <200310281129.10669.DavidJohnson@Siemens.com> References: <200310281533.26611.dgw@liwest.at> <200310281129.10669.DavidJohnson@Siemens.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 untrusted software. 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 description: Threats ------- 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. Solution -------- Basically: - Sandboxing - 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 > afterthought. 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 :)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1067374359.15026.126.camel>