[openbeos] Re: BeOS/Zeta is (not) immune to attacks
- From: "Zenja Solaja" <solaja@xxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Fri, 5 Jan 2007 23:09:47 +0000
It's always amusing to watch peoples reactions when the topic of multi-user
comes. The biggest fallacy is expecting a desktop system to behave like a
true old fashioned multi-user time sharing computer system, with one central
CPU and multiple terminals (with multiple users) connected at once. This is
NOT what Haiku wants to be (although an occasional telnet to a live box can
be useful).
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.
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.
Anyway, this topic really belongs in Glass Elevator mailing list.
Other related posts:
