OS Security
Home
Blog
Snippets
About

All timestamps are based on your local time of:

Posted by: stak
Posted on: 2007-11-19 19:56:25

I was reading Dan Bernstein's paper on security in qmail (via Bruce Schneier's blog), and his comments on single-source transformations (section 5.2) got me thinking. What he describes is a way (in *NIX) to isolate a program in a sandbox so that it can't do anything other than what it's supposed to. That means that the rest of the system is protected from any bugs in the program.

I was thinking about this, and it occurred to me that all OSs should do this by default. Programs shouldn't be able to open arbitrary files on the disk; there's no real reason to allow it. Programs usually only need to be able to access three kinds of files: (1) input files that are being processed by the program, (2) output files that the result is written to, and (3) settings/configuration files that the program has.

The third category is easiest to deal with: the OS should provide an API to load and store configuration data. Most OSs do this in some way, but usually through files. Instead, the OS should just provide get/set methods for a binary blob (or perhaps key-value pairs) to store per-program configuration data. It would be opaque to the OS, and therefore the OS would not be vulnerable to bad configuration data.

The first and second categories (input and output files) should be provided to the program only after permission is given from the user. In the vast majority of cases, the "Open File..." and "Save File..." dialogs could be used to implicitly obtain permission. The OS would be responsible for opening the file input/output streams and handing them to the program; the program wouldn't be able to arbitrarily open an input/output stream to a file.

There are some programs for which the above is not enough; mostly programs that do batch processing of stuff for which it would be tedious to manually approve every input/output file. In these cases, there could be some way for the user to batch-approve access to files (i.e. "VLC" can read all files matching "My Pirated Content/*.divx").

With current systems, one of the fundamental underlying principles is that a program run by user X should be allowed to do anything that user X can do, unless stated otherwise. I see no reason why this principle should be upheld. Programs having a lower privilege level than the user, such as described above, would probably go a long way towards preventing accidental and malicious data corruption.

Posted by rohan at 2007-11-19 22:55:48
Isn't that what the windows registry does? And it's such a mess.
[ Reply to this ]
Posted by stak at 2007-11-19 23:32:41
Kind of. The windows registry has a similar concept, but has a very botched implementation. For one, applications can read/write stuff all over the place. There's also no distinction between application settings and system settings. And of course, it's impossible to clean up the registry after removing an application, because the data could be scattered in unpredictable locations. That's probably the main reason it's "such a mess". Even so, it might have turned out better if applications used it consistently instead of throwing .ini files everywhere too.
[ Reply to this ]
Posted by varun at 2007-11-20 00:43:12
Not that I'm defending Windows here, but at least in Vista, there is a notion of registry virtualization, so you can write willy-nilly all over the registry without inflicting actual damage. Windows just silently redirects everything to a per-application registry setting. (More niftily, thanks to NTFS junctions, it also silently redirects file access - w00t!)

But broadly, I agree. What I would like to see in OSes is sort of the Mac model - every application is a folder - taken to an extreme: applications write settings to their own folder and are denied write permissions elsewhere, excepting user files. Read permissions are granted by virtue of the user initiating a read event through a file/open.
[ Reply to this ]
Posted by stak at 2007-11-20 09:05:41
(Re: Vista registry) Really? I haven't heard about that. How do they deal with backwards compatibility for apps that rely on the old behavior?
[ Reply to this ]
Posted by varun at 2007-11-20 11:08:02
Probably the best primer is Mark Russinovich's article but from what I understand:
-If a program is specifically designed for Vista, then it is verboten to write to the Windows folder and other protected areas, both in the FS and the registry and the program gets told Access Denied.
-If a program is not specifically designed for Vista, then the program is silently redirected.

I can confirm that this definitely happens here - there is a "Roaming" folder in my ~ directory.
[ Reply to this ]
Posted by stak at 2007-11-20 20:11:17
Yeah, that seems like a reasonable compromise. From the article it still seems like legacy apps all end up in the same virtualized file system, rather than each one getting an individual folder to play in.
[ Reply to this ]
Posted by varun at 2007-11-22 12:55:45
Belatedly, happy birthday.

I think, actually, each application gets its own "copy" of the FS to play with. Digging through my ~\Roaming folder, it seems that each app's required file is identified with a UID, so I have several variants of {9298ef8-ade92481-xxxx} shell32.dll in my ~\Roaming\..\Windows\System32\ folder.

It's a pretty effective way to solve the problem. As I've been saying, Windows Vista is much bigger for programmers than for end-users. The model at the back end has changed significantly for the better.
[ Reply to this ]
Posted by Fai at 2007-11-20 02:09:32
I think that's a bit simplistic. what about writing to a database, printing, loading a library, opening a port, accepting a file transfer? There are many valid uses for these actions.
[ Reply to this ]
Posted by stak at 2007-11-20 09:09:49
(a) Can you give examples of what kind of stuff you'd want database access for? This is probably a case-by-case thing.

(b) Printing should be the same as writing to a file - requires explicit user permission. This happens already; random apps don't start printing stuff until you hit the print button. In this model, clicking the print button would provide the print stream to the app.

(c) Loading a library - done by the OS anyway. It's not like you explicitly say 'fopen("foo.dll");' and then manually link the library into your program.

(d) opening an outgoing connection is fine, no restrictions needed. Programs that open a server port should be approved. There shouldn't be a lot of those anyway. One of the main reasons Windows is so vulnerable is because it leaves a crapload of ports open listening for various things, and all those listening apps have bugs that can be exploited. In the new model it's not as much of an issue because the rest of the system is protected, but still.

(e) Most definitely requires user permission. I don't random people to be able to send me virii without my knowledge.
[ Reply to this ]
Posted by varun at 2007-11-20 11:15:26
re: (d)

I think there should be no reason an outgoing connection should be made without your permission - if for no reason other than to prevent zombie spamming. If you can't talk to a mail server without the owner saying yes, you aren't contributing to the spamming problem.
[ Reply to this ]
Posted by stak at 2007-11-20 20:13:09
True. I was thinking primarily from the user-data corruption point of view, but preventing zombie spamming is just as important. I suppose things like web browsers which require multiple outgoing connections can simply be allowed to connect to http[s]://* (and ftp://* or whatever).
[ Reply to this ]
Posted by Fai at 2007-11-21 03:00:14
a) anything that uses a db as data store?

b) sure that's fine

c) isn't that exactly what you do in code? load a library and then call stuff in it? is "done by the OS" exempted if it's started by a user app?

so all of these can be solved by user permission. I thought you were saying could not be performed ever. User permission is reasonable, though annoying in cases, much like the vista uac

[ Reply to this ]
Posted by stak at 2007-11-21 20:46:10
a) Great example :p But a database could be provided in the same manner as preferences - via a OS API. There are already generic APIs for relational databases that could simply be exposed by the OS and implemented with any database internally. Again, it would be app-specific to minimize cross-application data corruption.

c) It's the OS that loads the library. You request the load and call stuff in it. At no point do you have to actually read from a file.
[ Reply to this ]
Posted by Fai at 2007-11-23 15:53:45
a) eh. make an arbitrary app with a db. patient history recorder, library or store catalogue. Why make it an OS thing? Why should the OS be responsible for the db a user wants? What if he wants a private db just for his app? It doesn't seem sensible. Especially, since now he needs user permission every time he writes to it (or once per session?)

c) so you want user permission for every library loaded? Past 6 questions, you know I won't even read the dialog.
[ Reply to this ]
Posted by stak at 2007-11-24 13:44:31
a) Hmm. Not sure about that one.

c) No, no user permission required because it's the OS that does the file reading.
[ Reply to this ]
Posted by Fai at 2007-12-01 15:30:13
c) if I don't give permission, then isn't that the exact model we have now? an app can invoke OS functions. Isn't that what you started off saying was wrong? That you should have explicit acks for OS operations?
[ Reply to this ]
Posted by stak at 2007-12-01 16:00:04
No, I started off saying apps being able to do direct file manipulation was wrong. I'm fine with them requesting OS operations.
[ Reply to this ]
Posted by Fai at 2007-12-01 18:26:22
what's the difference if the OS doesn't have some sort of permissions policy and grants all requests?
[ Reply to this ]
Posted by Varun at 2007-11-24 16:25:36
Fai has a point - suppose you have to comply with regulation that requires secure and verifiable database storage, for example, HIPAA or Sarbanes-Oxley in the US; equivalent things in the rest of the world. Right now, as long as your application is hardened and secure, the OS can be compromised. But in the OS is responsible model, if your OS is compromised, then all the data is potentially tainted and so you're running afoul of the law. Which isn't a problem for a mom-and-pop shop app, but if you're running something like a investment consultancy or clinic, you're likely up a creek without a paddle.
[ Reply to this ]
Posted by rohan at 2007-11-24 15:26:06
has your site been invaded by spam comments?
[ Reply to this ]
Posted by varun at 2007-11-24 16:18:17
Mine too. I have it setup now to not publish a comment unless there's at least one dictionary word in it and, if there is a single link, it resolves. Anything with more than one link gets held automatically. So far, between that and Akismet, I'm okay.
[ Reply to this ]
Posted by stak at 2007-11-24 18:43:30
It would appear so. Let's see how they deal with my new-and-improved captcha.
[ Reply to this ]
Posted by Varun at 2007-11-24 21:50:46
Clever.
[ Reply to this ]
Posted by rohan at 2007-11-26 12:00:24
how would spammers even get to a site that doesn't use a standard blogging site? wouldn't they have to manually configure their spammer just for stakface?
[ Reply to this ]
Posted by stak at 2007-11-26 19:31:29
Not necessarily. They could implement a generic bot that looks for the textfield/textarea combo near words like "comment" or "reply". Images located within the form would likely be captchas. Assuming they blindly paste the results of their image recognition into the text field, the new captcha should stop them.
[ Reply to this ]
Posted by rohan at 2007-11-27 00:03:47
checking out new captcha...
[ Reply to this ]
Posted by rohan at 2007-11-27 00:04:18
again with no login...
[ Reply to this ]
Posted by Fai at 2007-12-01 15:31:50
ooh I want to play too.
aah. nice :)
but wait, I think you know my chronic problems with math! I think this is all a convoluted attempt to prevent me from posting!!! :)
[ Reply to this ]

[ Add a new comment ]
 
 
(c) Kartikaya Gupta, 2004-2024. User comments owned by their respective posters. All rights reserved.
You are accessing this website via IPv4. Consider upgrading to IPv6!