A new kind of security needed

[Tim Clewlow]

On Thu, Jul 24, 2008 at 9:56 PM, Szilveszter Adam <sziszi at bsd.hu>
wrote:
> On Fri, Jul 25, 2008 at 01:18:25PM +1000, Tim Clewlow wrote:
>> Some more thoughts.
>
> <...>
>
>> The existing DAC method already provides sufficient protection (we
>> all hope) to system objects, often via root/wheel. What we really
>> want is a mechanism to protect user data from being clobbered by an
>> errant program. By extending the traditional DAC with an Application
>> ID (AID) the kernel could allow or deny processes that are part of a
>> particular application from accessing a file based on the rwx flags
>> of the AID for a particular user file.
>
> This idea may work quite well for a server (and already does,
there are
> several implementations out there). But for an interactive desktop
> software that a user drives in real-time (like firefox, as you
mention)
> this does not work. Think about it: You want firefox to not touch
your
> files in your ~ directory, so you configure FF in this way. But then,
> somehow you come to the very unlikely idea that you want to actually
> download something from the web. (eg a PDF manual for the latest
gadget
> that you bought) Or upload one of your photos to an
> online album (as Robert Watson has already pointed out). What now?
FF is
> not allowed to touch your files, so will not be able to do at
least the
> first case (because that requires write access to some location in
order
> to save the file) but quite possibly the second may not work either,
> after all, why would you want FF to read your office documents, so
you
> have already denied that as well.
>
> There is no secure and usable solution to this problem, as Robert has
> already pointed out. The whole notion of sandboxing rests on the idea
> that the behaviour of an application is very deterministic (it
only does
> A, and never, ever, anything else, during normal operation) and
not very
> complex. Typical desktop software is already very complex, has a
lot of
> functions and is not deterministic almost by design: there is a human
> sitting in front of it, doing this on one occassion and something
else
> on another. If you allow everything that the functions of the
software
> might cover (or only a reasonable set) you are already almost at the
> status-quo: You have to allow access to many-many objects, many of
which
> are not in use most of the time, some are not in use ever, but who
> knows.

I'd like to offer a possible solution that I believe can be both
secure and usable. This will use the AID concept outlined above.

(Note, when I refer to a rwx flag in the following paragraphs, I am
talking about a flag in a 4th group, ie in addition to the normal
user/group/other set of flags, lets call it the app set - in
addition, there is an associated AID for any of the 3 of those flags
that have been set, ie there can be up to 3 different application
ID's set for a single user file)

When a user file is created, the kernel sets the read flag, and sets
the AID for that flag to 0 (0 being a special value), the intention
being that this means any application can read the file. Next the
kernel sets the the write flag, and set the AID for the write flag
to be the same as the application that is creating the file. (If at
some later time the user wants to limit reading to a single
application, then they can with the equivalent of a chmod for AID)

Using this method, an errant application will only be able to damage
data files that it owns. It also means if an application wants to
create a new file, then it can. This solves the problems presented
above. (If the file about to be created already exists, then as long
as the application owns the file, it should be allowed to overwrite
it as it should already have write access)

For systems with this enabled, ie desktop systems, this would, for
the majority of data files, work quietly in the background without
the user even being aware of what is going on.

One place where some work would be required is during the
installation or upgrade of an application, ie as part of the
installation, there would need to be some provision for acquiring
the AID that the application will eventually be given by the kernel,
and then setting the write AID value accordingly for any data /
config files that may be created during installation. This is part
of what I was referring to when I said the implementation of AID
would create a system that has some important differences from a
vanilla FreeBSD system.

Anyway, I just wanted to offer this as being a potential way of
overcoming some of the pitfalls pointed out above. Yes I know I am
being persistant, and probably a bit annoying too. I dont mean it to
be, I just would like to explore the possibilities of enhanced
security that may be available.

Feel free to shoot holes in any/all of this, I may have painted a
big target here :-)

Cheers, Tim.