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
Xavier

--

Unix is very simple, but it takes a genius to understand the simplicity.

(Dennis Ritchie)

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
--

TFMotD: eqn (1) - format equations for troff

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...
[ message continues ]

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 ...
[ message continues ]

This is a common response from OpenBSD fans when confronted with SELinux
Unless I am sorely mistaken, systrace can be broken by any user with

enough priviliges to run two processes.
I'm not really aware of any non-root problem with securelevels, but

since securelevels are almost entirely about restricting root (and not

other users - an ordinary user wouldn't notice the difference), this is
		Joachim
--

PotD: x11/gnome/utils - GNOME utility programs

Well, then you are sorely mistaken.  One of your processes can break

the other one.  What's the big deal.  Where's the priviledge

escalation?  There is none.
You overstate the situation.

Not at all, and changing the thread title when changing the thread
I'm not aware of any current `replacement' for systrace in OpenBSD. This

is both a blessing and a curse; systrace gets its tentacles deep into

security-sensitive code, and I remember at least one instance where that

caused a bug (though not what bug).

On the other hand, systrace allows one to express a security policy
It's not entirely impossible to improve on OpenBSD's default security,

although the default security is pretty good. The most obvious

improvement is disabling SSH logins using passwords, as has already been

mentioned.

It might also be a good idea to periodically audit /etc/master.passwd

for weak passwords. John the Ripper <http://www.openwall.com/john/>

might be useful here.
There is also something to be said for dropping all IPv6 traffic; the

IPv6 stack is not as thoroughly tested as the IPv4 stack, despite a lot

of work by the smart people of the KAME project.

In the same vein, a restrictive pf configuration might help prevent or

at least mitigate the effects of exploitation.
You could also take a good look at /etc/login.conf; it does a pretty

good job of limiting resource usage, but it's a bit more lenient than it

could be, especially for the 'daemon' group (daemons very rarely really

need the ability to allocate an unbounded amount of memory). It should

be noted that the 'daemon' group appears to be used only by ports,

though.

However, this merely prevents an attacker that has already gained access

from DoS'ing the rest of the applications on the machine.
If you have local users, you might also want to vet suid applications.

You could also move the 'root' entry in /etc/master.passwd away from the

first line; if there is a programming error whereby a suid app that can

be told to parse an arbitrary file, the password hash for root cannot be

discovered (see

<http://labs.idefense.com/intelligence/vulnerabilities/display.php?id=157>

for an example of this problem; while this is n...
[ message continues ]

As others have already pointed out these knobs might not be useful to

your setup and your needs. Think also that more complexity you add

then more likely you'll find out bugs lurking in the dark, waiting for

the right moment to bite your ass.

I have a box running FreeBSD with MAC policies configured in

production for a year now; I must be honest, the only thing I'm really

sure about is it's a royal pain to update and manage. Not a great

deal, I'm planning a switch to 4.2.
f.

The white paper for the systrace vulnerability was a little bit beyond

me; what's the impact of the issue?  Is a system running systrace *more*

vulnerable than a normal system, or is the problem just that a

determined user can circumvent systrace (like the bottom of systrace(1)

suggests)?  If it's the latter, it seems like it'd still be useful for

policy enforcement to some extent.

two processes using shared memory can cooperate to circumvent

systrace.  this means it's not very useful to contain an app after

exploitation.  also, circumvention is not "silent".  if you log

failures, you'll see it happening.
systrace is still useful for keeping an eye on binary programs.  or to

make sure your apps are configured correctly (web server can't read

files outside of blah/, whatever).

Robert Watson's paper discusses concurrency vulnerabilities. Impact

include policy bypass and audit trail invalidation. A bypass means it

is useless. That pretty much hammered in the last nail on the coffin

for security tools based on system call interposition.

I actually dont think it is all worthless. Imagine a machine running a

server daemon. If you systrace that particurlar daemon to not be able to

fork()/exec*() or system(), you could be quite sure it wont start random

apps on your machine in case someone manages to trick it somehow.
Now, if the attacker already has a local account and/or shell, he might

run races and fool the systrace. But if this daemon was the only way for

said attacker to gain such shell access, and it can be prevented from

doing common stuff needed to get a local shell then you would have a

"safer" system.
In this way, systrace might be usable still, even though it wont suffice

for systrace'd shells given out to bad guys. Same as all other measures

you might have like chroots, stack gaps, randomized mem layouts and

library addresses, they never prevent 100% of all attacks, just many of

Oh really?

The abstract reads "System call interposition allows the kernel security model

to be extended. However, when combined with current operating systems,

it is open to concurrency vulnerabilities leading to privilege

escalation and audit bypass."

(Paper at <http://www.usenix.org/events/woot07/tech/full_papers/watson/watson.pdf>)

and Neils Provos says

<http://www.systrace.org/index.php?/archives/14-Evading-System-Sandbox-Containment.html>

"The initial prototype of Systrace as described in the paper avoided

this problem by using a look-aside buffer in the kernel. This imposes

a slight performance penality but I hope that this obvious solution is

going to be included in the OpenBSD and NetBSD kernel soon."
How is this the "last nail" at all?
-Nick

On 10/14/07, Aaron <ml@proficuous.com> wrote:
You're asking the right questions. Some of the answers, unfortunately,

aren't as cut and dry as one might hope at first, and this stems from

the fact that some security measures are sometimes subjective. What

one person might see as a good hardening measure might be considered

completely useless to another person. Ultimately it comes down to

whether you feel a hardening measure makes sense for the gap you're

trying to cover in your circumstance.
OpenBSD goes a very long way toward providing a very hardened Unix

system out of the box, without you having to flip a set of switches to

turn them on. You can see them everywhere. Run a web server using the

included httpd and you'll have the benefit of chroot'd operation. Run

the in-tree BIND as a nameserver and you'll find that it employs a

number of security improvements out of the box which make it a safer

system. This kind of stuff exists everywhere in the system and they

are examples of real, practical, and effective things which a.) do

improve security of a system against known threats, and b.) don't

required complicated decisions by the admin to kludge them into place

(a la some of the policy wrappers that exist out there.)
Figure out your threat profile for your anticipated use, figure out

from that how those threats will impact the services you intend to

run, and address those with controls you feel you can put in place

that can mitigate those threats. External controls might help, like

firewall or IDS/IPS, and don't forget  you can use PF locally. See if

you think a file integrity checker makes sense. Don't run things as

root that don't need to. See if you can help things out with policy

and technical enforcement to back it up (like if you have shell users,

and you're afraid they'll choose weak passwords, configure SSH to only

support key-based authentication and make that your authentication

policy. ...and so on.
DS