Aaron wrote:
Joachim Schipper wrote:
On Thu, Oct 11, 2007 at 08:54:42PM +0200, Xavier Mertens wrote:
Hi *,
I'm busy with a systrace/stsh implementation but there is a lack of
standard
policies (IMHO). Any idea where I can find some ready-to-use policies?
I must be missing some important ones, when the user logs in, he got
immediately
the following error:
systrace: getcwd: Permission denied
You should probably do a Google search on systrace before continuing
further down this road. In particular, I believe the issue highlighted
by Robert Watson has not been fixed yet (although I could be wrong, and
would be happy to be wrong in this case).
Otherwise, I seem to recall a repository of configurations called 'hairy
eyeball'. And the interactive policy generators (xsystrace for instance)
can be pretty useful, too.
Joachim
I hope i'm not out of line changing the thread but this seemed like a
good place to ask this question.
I'm fairly new to OpenBSD and have set up a few machines, nothing
production, trying out configurations, rebuilding, patching etc.
before i felt comfortable putting one in production. One thing I did
read up on, where i could find it, was hardening beyond the default
install. Two of the tools that most of the hardening articles i
found, Securelevels and systrace, (the third one seems to be common
sense), have now seemingly been rendered useless. I followed the huge
thread on "why can't openbsd's securelevels be saved" and now this
thread has alerted me to the fact that systrace is able to be
circumvented. I also noticed that Joachim commented on both so I
figured this for a good place for this topic.
I'm wondering if there are other tools/ways besides these that I
just haven't heard of to do similar things(hardening of the system) or
if there is in effect no way to do the things that, these two tools,
specifically systrace has historically handled(is there really a need
in the first place?). I say specifically systrace because from the
discussions i've been reading, the whole securelevel methodology, to
the people that do the work on OpenBSD, is flawed. I'm not here to
dispute or even to discuss that point, as currently I can't program
(nor afford to hire people that can) so my likes and dislikes are moot.
Like i say, i'm still relatively new to OpenBSD so I'm just looking
for insight, I haven't used systrace in the past, and until about a
week ago was working with securelevels but then found the
aforementioned article. I had abandoned the securelevel method in
light of the 'issue'(s)/false sense of security with securelevels and
from the discussion had decided to pick up with systrace, until i saw
this thread yesterday.
Is it more common than not, to not worry as much about "hardening"
the OS, via these methods, but rather just to make 'hopefully' wise
decisions, install the least amount of software as you need, physical
separations(i.e. logging to remote server instead of sappnd'ing your
logs)(but what happens when after getting root on the system producing
logs, the attacker proceeds to work towards your logging server?) and
stay current w/at least the stable branch?
I guess with all the hoopla about 'hardening'/trusted this and
that/fuzzy knobs(i.e. SE Linux) i got a little overzealous looking for
ways to tweak things (which i know can end up either making things
less secure (especially with false sense of security) or just plain
breaking them), but if there is/are acceptable, ways, I'd at least
like to be aware of them and the scope of their use from the people
that know OpenBSD best.
Thanks,
Aaron
Thanks to everyone for answering/explaining what i know is in no way
an easy question to answer with really an infinite number of answers
depending on the skill set of the person answering and also the level of
the person asking. Like I said originally I'm fairly new to Openbsd,
and to be honest, when i read that securelevels was able to be defeated
and to move to systrace, i was a little overwhelmed reading up on it and
looking at the examples. The types of machines I will be running (when
i feel comfortable enough with openbsd)(and am concerned about
protecting, should i be more concerned about protecting my OBSD
workstation too? I run pf and only allow pass out w/return traffic
allowed, no services at all) will be single or dual purpose servers..
i.e. http, smtp, imap etc, not machines that are running X and all my
fav ports like amule (not that i would ever download anything from there
anyway, that's just not safe :-)) I don't allow remote logins even via
ssh except for the local networks, I always have a firewall in front of
my public servers with rate limits (overload for pf fans) and I had
decided a while back i was going to forgo the new bells and whistles in
the latest and greatest versions of software, due to
simplicity/security's sake. and only run packages for the services I
need, even though often times i get frustrated that things don't get
brought current with every new release (i.e. hylafax or dspam). _NOT
COMPLAINING_, just giving an example.
Maybe it's good that these things came up with securelevels and
systrace because to be honest , I'm not sure I would have been up for
upgrading like I should with securelevels and i _know_ I would had a fit
trying to get systrace policies set up, if not worse thinking i had them
set up right and figuring out later they weren't and i had in fact
lessened the security by putting all my trust in that system, at least
at this point in my experience. From what I have comprehended both of
the security mechanisms that have been "broken" still need to have
someone that has gained root on the box (not that my understanding might
not be flawed), which is one of the things that OpenBSD strives to disallow.
For now I think I'll stick with the minimalistic type install,
choosing software with a good security history, doing my best to
configure things as safe (chrooting, using login.conf, running things as
non-privileged users, etc...) as possible, as people have suggested,
sticking with the openbsd package system and keeping a close eye on the
systems via some of the suggestions made in this thread and in others on
this list. Perhaps by the time systrace is fixed or the next mechanism
for securing beyond default install and common sense, if the teams
decides to go the fixing systrace route, I'll be better prepared to
utilize those tools.
Thanks to the OpenBSD team for all the work and help.
Aaron
