Re: hardening BSD (was systrace/stsh policies)
On Mon, Oct 15, 2007 at 09:30:02PM -0500, Aaron wrote: The types of machines I will be running (...) I run pf [on my workstation] 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 (...) 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 (...) and I had decided a while back i was going to forgo (...) the latest and greatest versions of software, due to simplicity/security's sake. Sounds pretty good. (...) [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. This is a common response from OpenBSD fans when confronted with SELinux and the like. From what I have comprehended both [systrace and securelevels] 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. 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
Re: hardening BSD (was systrace/stsh policies)
Unless I am sorely mistaken, systrace can be broken by any user with enough priviliges to run two processes. 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.
Re: hardening BSD (was systrace/stsh policies)
2007/10/14, Aaron [EMAIL PROTECTED]: 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 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.
Re: hardening BSD (was systrace/stsh policies)
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. On 10/15/07, Steve Shockley [EMAIL PROTECTED] wrote: Joachim Schipper wrote: 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). 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.
Re: hardening BSD (was systrace/stsh policies)
On 10/15/07, Eduardo Tongson [EMAIL PROTECTED] wrote: 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. 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
Re: hardening BSD (was systrace/stsh policies)
On 10/14/07, Steve Shockley [EMAIL PROTECTED] wrote: 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).
Re: hardening BSD (was systrace/stsh policies)
Eduardo Tongson wrote: 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 them. On 10/15/07, Steve Shockley [EMAIL PROTECTED] wrote: Joachim Schipper wrote: 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). 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.
Re: hardening BSD (was systrace/stsh policies)
On Sun, Oct 14, 2007 at 03:27:20PM -0500, Aaron wrote: I hope i'm not out of line changing the thread but this seemed like a good place to ask this question. Not at all, and changing the thread title when changing the thread subjet is a welcome relief from the usual misc@ practice. I'm fairly new to OpenBSD and have set up a few machines, nothing production (...). One thing I did read up on (...) 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'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. 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 that's more fine-grained than the default UNIX permissions allow. 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. 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 not the only example I know of, this problem is not particularly common). This also isn't much of a problem if root has a password that is too complex to bruteforce, which should be the case. It could also be argued that, should you require an MTA that is accessible from the outside world, replacing sendmail with your favourite alternative may increase security. Finally,
Re: hardening BSD (was systrace/stsh policies)
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
hardening BSD (was systrace/stsh policies)
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
Re: hardening BSD (was systrace/stsh policies)
Joachim Schipper wrote: 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). 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.
