[ge-talk] Security services provided by OS

[Zenja Solaja]

<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.

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.

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.

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.

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.


So what sort of services do we provide in Haiku R2?  This is the forum for
way-out-there ideas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.bug-br.org.br/pipermail/glasselevator-talk/attachments/20070106/272d3b92/attachment-0001.html