Linked by Thom Holwerda on Fri 5th Jan 2007 20:11 UTC, submitted by sogabe
Zeta MauriceK writes about security in the ZETA operating system. Apparently magnussoft, sole distributor of ZETA, makes security claims [on the German version] that with ZETA "it is not possible to examine a system from the outside without notifying the user due to the architecture of this software." MauriceK seems to think differently, and even gives examples on how code can be executed without the user's knowledge in ZETA. In related news, BeUnited is no more. Instant update: the discussion concerning security just made its appearance on the Haiku m-l.
Thread beginning with comment 198850
To read all comments associated with this story, please click here.
mailing list comment
by Nicholas Blachford on Fri 5th Jan 2007 23:03 UTC
Nicholas Blachford
Member since:
2005-07-06

I thought the subject raised on the haiku mailing list was much more interesting:

There's nothing to prevent a user from running a malicious application which wrecks their home directory.

When this question is raised it is never taken seriously, why?

Reply Score: 1

RE: mailing list comment
by looncraz on Sat 6th Jan 2007 01:34 in reply to "mailing list comment"
looncraz Member since:
2005-07-24

It is not taken seriously because the home directory will likely become 'roaming' or otherwise protected with the inclusion of multiple user support. At that time ( Hailu R2, maybe ) some greater concern for 'malicious attack prevention' will surface. And then, it will mostly be handled through the code that provides the means to switch users, or in the kernel.

Currently, the only guarantee you have on BeOS is that there WILL be a /home directory. It doesn't mean the contents are safe ( in fact you can delete /home and watch it magically re-appear so fast it'll make your head-spin).

Fun, huh?

--The loon

Reply Parent Score: 1

RE: mailing list comment
by Soulbender on Sat 6th Jan 2007 08:49 in reply to "mailing list comment"
Soulbender Member since:
2005-08-18

"When this question is raised it is never taken seriously, why?"

Because it is what backups are for and it has nothing to do with *security*.
It's like saying "I want a hammer that won't let me destroy stuff in my home...unless I actually want to destroy stuff in my home".

Reply Parent Score: 4

Nicholas Blachford Member since:
2005-07-06

Because it is what backups are for and it has nothing to do with *security*.
It's like saying "I want a hammer that won't let me destroy stuff in my home...unless I actually want to destroy stuff in my home".


This is a very bad analogy, a hammer isn't likely to go round the house and destroy stuff of it's own accord. I have to physically pick up the hammer and do the damage myself.

On a computer the "hammer" can do it all itself without any user intervention. What's more, the hammer can pretend to be a pretty picture hanging on the wall, so you don't even know it is a hammer.

The problem is any file in my home directory can do whatever it likes. It should be the other way around, it should only be able to mess around with other files if I say so.

Reply Parent Score: 1

RE: mailing list comment
by molnarcs on Sat 6th Jan 2007 15:17 in reply to "mailing list comment"
molnarcs Member since:
2005-09-10

When this question is raised it is never taken seriously, why?

It is taken seriously, but there are no easy solutions. It was somewhat amusing to see how Zenja Solana's proposal begins with a bold note:
Protection #2 (prevent application from destroying files) actually has a very simple solution which no OS really uses, which is quite puzzling...
... only to fall apart towards the end. See how the restrict writing to only the apps' directory quickly become restrict writing to apps directory... and oh, the config directory... and oh yeah, the file directory as well. And if you think of this last one, this works only if there is a "hardcoded" place for each filetype, plus there is only one application for each file type (just think of it!). In other words, the only way of protecting important data is to backup them regularly -- there is no easy way to protect user directories without seriously limiting the system's flexibility.

On the other hand, one should not downplay the importance of a multi-user system, like the above post does. Just one example: I run apache on machine, under user:group www:www. Now if a remote attacker founds an exploit in the code of my website, it can probably get access to my system. Actually, I got haXored once this way (and it was my fault, didn't update geeklog for months, even though there were known security vulnerabilities). What happened is that the attacker gained access to files that belonged to www:www, and could write to places where www:www could. Which means, that all my data files in my home directory were safe (because the remote code execution vulnerability would have to be combined with a local privilege escalation vulnerability in apache itself, and the two happening at the same time has a ridiculously low chance). Where I using Zeta, the attacker would have complete access to all my files. That's a significant flaw in Zeta's design.

So, to sum up: the question you refer to is being taken seriously, but the solution is not trivial (it is trivial, but that would mean the end of control over you computer). In the meantime, real security issues (non-encrypted central contact list storage??? - how easy is to solve that for god's sake?) that can be solved and were solved in every other OS should be taken care of, instead of downplaying their importance or impact.

Reply Parent Score: 2