[EMAIL PROTECTED] wrote:
Ever heart of a multiuser system where one user shouldn't be able to
acces the files of another user? Not all users are thinking about this
issue and many forget to change the modes for confidential files. IMO,
But keeping confidential files on "true" multiuser systems is stupid ...
I disagree, How about a heavy build server for different projects?
Or shared (insert word)-solutions. You cannot be to careful with your
files, one day, as normal user, you will forget to chmod() that file ...
Whenever you configure a box like that, you will (have to) put more
thought into it in the first place. You cannot assume that a default
installation of any general purpose OS, including OpenBSD, can serve
each and every possible purpose right out-of-the-box. There has to be
done some careful, custom configuration. The cleanliness and lack of
nasty surprises in OpenBSD might make this easy (or at least easier) to
implement, but the design part is always the same. It's just as with pf
- the way it works, syntax etc, is easy to understand and use, but in
the end it also just does what it's told to do ... and if that part is
flawed, the result will be flawed as well.
I have yet to find an "insane" default setting in OpenBSD. It all makes
perfect sense, and it's wonderfully simple to go into any direction from
these defaults. I see no reason in changing them into what's more
suitable for special cases. The things you mention are/can be pretty
large projects.
Paranoia never really helps security -- all it can do is prevent people
from thinking straight... or worse, make them alter paranoid default
settings into utterly insecure ones just to get things working again -
depending on whose paranoia needs to be dealt with. In my opinion, the
OpenBSD folks are walking a fine line here and doing a good job at that.
IMNSHO. And you cannot hide anything from the administrator. You depend
on how well the admin is capable of securing the rest of the system and
not have it rooted by a 3rd party(*) including the other users.
Then you shouldn't use the system at all. It is not because something
might be/become a flaw, that you don't have to care about the rest.
Every extra layer of defence _does_ protect you from a subset of attacks,
even how small that subset is, it counts.
As for how far trust goes, this needs to be figured out on a
case-by-case basis. You trust because something is made trustworthy -
for example through transparency in what way security is enforced. But
this digresses from talking about default settings, and in this regard
there might've been a misunderstanding.
I did not mean to not care about the rest, but you cannot expect most or
all of it from a default installation. I hope my explanation above is
clearer. The fine line is to have things secure but not paranoid (and
thus dysfunctional for the majority of users.) I disagree with the
proposed changes to /etc/skel, because I believe that what we have here
is perfectly suited for most people, and easy enough to work with for
those who have special needs.
shell server. Who says that the admin is any more trustworthy than some
other, regular users?
They are not, but most of the time they give you confidential information
that you must use on that box that you use for stuff other users may
not access, like database/pop3 information.
Huh, why would I give shell access (or even a system account) to anyone
but fellow admins on a database or mail server in the first place? From
a user perspective, I for one would rather Post-It[tm] complicated and
unmemorizeable credentials to my monitor(*) where I have at least some
idea about who might get to see them instead of putting them into my
home directory on my own server at home, let alone some server someplace
else.
Moritz
*: Just like some well-known security guy, whose name I forgot,
suggested recently ... might've been a TheRegister article pointing to it.
