[ge-talk] Security services provided by OS

[Michael Phipps]

Hi Zenja! Long time, no hear from! :-D

Zenja Solaja wrote:
> <post from open-beos at freelists.org
> 
> What do users **really** want when it comes to security services 
> provided by
> OS?
> 
> What people actually want from a 'secure' OS is four types of protection:
> 1) keep my confidential data away from prying eyes (ie. don't allow the 
> kids to delete tax return)
> 2) prevent locally run applications from destroying your data and the 
> system
> 3) control remote access capabilities.
> 4) prevent a rogue application from tampering with a good application.

I really like this list.

> At first glance, protection #1 has already been solved by other OS's by
> introducing an access rights policy.  Haiku already has a file system which
> stores UID and read/write access info, what it lacks is a kernel mechanism
> to enforce this.  But then again, how do you prevent little Brian (ie. your
> teenage kid) from downloading a hacked file system driver and kernel which
> bypasses access rights checks.  The only real option is encryption, and
> backups.  So maybe instead of bothering implementing access control hooks
> into the kernel and file system to support UID/s per file/directory, maybe
> we should go down the encrypted directory/file path instead, since this is
> ultimately the problem we want to solve.

Actually, I am fairly sure that we *DO* enforce UID and read/write. R5 did, 
and I think that we have already finished this. If not, we will. The issue 
is that R5 wasn't set up in such a way that you COULD log in as anyone 
other than (basically) root. Things broke if you did. That is fixable (Zeta 
has fixed it, we can too). Your point about the hacked file system is 
valid. Since we allow add-ons in your home directory, it would be tough to 
prevent this.

> Protection #2 (prevent application from destroying files) actually has a
> very simple solution which no OS really uses, which is quite puzzling.
> Simply restrict the application from only modifying files in its current
> directory or lower, but never higher.  ie. an application in
> /boot/apps/Sandbox  can only modify files in the Sandbox directory and 
> lower
> (and obviously ~/config/settings/Sandbox).  If an application needs to do
> anything outside it's boundaries, pop up an alert asking for permission /
> password.  There is also a third directory which we will allow access to,
> and that is wherever the user open/saved a file to.  This approach allows
> audio players to access my MP3 directory, but never /boot/beos/system).
> Spawned applications inherit directory restrictions.

This is an interesting idea that I have never heard anyone propose. It 
reminds me, sort of, of some of the discussions of years ago wherein Alien 
Soldier (I *THINK*) proposed that applications have very limited 
capabilities by default and the user would have to grant them more. Take, 
for example, Midnight Commander or some Tracker replacement. What you have 
proposed would not work well for that sort of an app. Additionally, what 
stops me from loading /boot/beos/system/kernel, modifying it, then saving 
it and breaking my system? Sure, the user has to get tricked into doing it, 
but that is fairly trivial to do. This depends on the file requester being 
secure.

> Protection #3 (remote access) boils down to inheriting access rights of
> server application.  If you FTP into the box, then you can only access
> directories configured via protection #2.  If, for instance, you run a web
> server with a buffer overflow / maliscious code vulnerability, you can only
> destroy files in restricted directories.

That's sort of hard to define, too. That wouldn't allow you to run, for 
example, NFS or SMB as a network service.

> Protection #4 (rogue app tampering with other running apps).  This will be
> hard to enforce, since ultimately we actually do want this capability in a
> feature rich environment (ie. send messages between 2 apps).   In the most
> evil scenario, App#1 can send mouse moved / keyboard messages to app#2,
> which essentially allows app#1 to gain app#2 directory access rights for
> limited tasks.  We cannot really stop this without alienating the user with
> too many popups/alerts.  But a simple popup with "Allow once / always allow
> /  dont allow" option can suffice.

(psuedo-messaging)
hey tracker select all
hey tracker delete

> So what sort of services do we provide in Haiku R2?  This is the forum for
> way-out-there ideas.

 From memory, here is what we talked about years back. I am probably adding 
to and removing from, so any mistakes are mine...

There is a default app configuration, something like:
can use 500k of memory (in addition to the executable being loaded)
can spawn normal priority threads - 1 for each CPU, max
can write to ~/settings/appName/* (via a nice settings api)
can read/write files that it is registered for (not necessarily as the 
default app)

That's it. Anything else is denied.

There are categories of additional priv's:
game (can spawn multiple real time threads, can take over screen)
network (can open sockets)
file reader (can read any file)
file writer (can write/overwrite any file)
file manager (can read/write/delete any file)
heavy memory/threads/windows

An app can ask for any of these and have the privilege granted never, once, 
  forever.