
|
[openbeos]
||
[Date Prev]
[01-2007 Date Index]
[Date Next]
||
[Thread Prev]
[01-2007 Thread Index]
[Thread Next]
[openbeos] Re: BeOS/Zeta is (not) immune to attacks
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Fri, 5 Jan 2007 20:45:35 +0100 (MET)
"Niklas Nisbeth" <noisetonepause@xxxxxxxxx> wrote:
> This was widely reported on BeOS news sites, but I wanted to just
> throw it out here. While security is obviously not going to be a big
> issue in the real world any time soon, I think these issues need to
> be
> looked at and addressed BEFORE we achieve world-domination, so we can
> send the black hats & script kiddies to /dev/null from day 1. Some of
> the points Maurice make are good...
He's just stating the obvious. There are *many* more problems in BeOS
to solve to have a secure system. For one, the whole port and semaphore
system is a security disaster as it works now (everyone can write to/
read from any port, and everyone can acquire/release any semaphore -
only kernel semaphores are somewhat protected).
> And while we're at the security discussion, can I just reiterate a
> point I make whenever I get the opportunity: People talk about
> multi-user as though it's the holy grail of computer security, and
> that you must have it for your systems to be secure. I'm not
> convinced: all the stuff that's actually important to me is in my
> home
> folder; that's the stuff I do backups of, and that's what I'd miss if
> it was erased. Multi-user doesn't change that, programmes I run can
> still erase my home folder, there's no check there. Rendering my
> system unbootable by wiping /boot/beos is a nuisance at best if I
> have
> an installation CD. I don't think rm -r /boot/beos/* is something we
> need to be concerned with, but rm -r /boot/home/* is a *very* big
> issue.
There will never be a method to stop *you* from erasing *your* home
folder. That's not what security is about, that's what backups are for.
Security comes into play if you want to prevent someone else from
erasing your data. For example, you might want to test unknown
applications in a secure shell first, so that you'll see if they are
malicious or not.
But eventually, it all boils down to if you trust the source of the
application enough to run it or not; security is there to make this a
conscious decision, but it doesn't protect you from yourself.
Of course, with ACL you could only allow Tracker to delete files in
your home folder to be a bit more on the safe side.
Bye,
Axel.
|

|