Theo says you should use full paths and shouldn’t run commands from the current directory.

noexec /tmp

nat said if you want untrusted users then chroot them. Do you trust random website users.

Most people will block ipv6 as it is still becoming stable and not widely used. I know I did. You can make ipv4 as secure, in fact more secure with a bit of work anyway, though you may run out of addresses.

There is a lot of truth to everyone being vulnerable to DDOS especially with the likes of conficker around. Whitehouse, microsoft (were lucky) and A small attack from russia making authorities consider cutting off parts of the internet spring to mind.

They also state 2 remote holes, is a dos a remote hole.

Security is a process not a product. (Bruce Schneier)

Update: naturally, ignoring my warning here, and per own previous statement that phe would now just ignore me, Nat posted yet another comment. I’ve removed it, as promised. Nat, if you’d like to have a voice, stop posting anonymously. I’d respond privately, but since you haven’t given me a real address…

If you want to have meaningful conversations on the Net, you need to learn to keep a reign on your emotions. Slewing insults does not a sound argument make, and if your arguments are in fact solid, you only damage them by acting like a child. You do not impress anyone by threatening to ignore them in the future: if you find that someone is worth ignoring, the very best course of action is to just start ignoring them.

Right… guess you’ve forgotten why Unix supports multiple users in the first place, then. Sheesh. Just because you sell someone an account on your machine, doesn’t mean that you just assume they’re trustworthy.

Why bother with users at all? Why not just give everyone root access?

You’re a fool Micah, and I assumed you were smarter than that.

Right. That statement somehow makes you look so much smarter than me. What are you, fifteen?

When a bank locks down to prevent a robbery, is that now somehow not a security measure? The goal is to maintain the funds contained therein, is it not? To maintain the security of the capital and materials which the bank holds? A lock down prevents access to those resources, but it maintains there security. A denial of service is that failed robbery. The security of the data is maintained at the minor inconvenience of not gaining immediate access to it, that is security.

You’re a fool Micah, and I assumed you were smarter than that, I am sorry for the inconvenience, next time I’ll just ignore you.

That’s a silly statement. Obviously, GNU systems have OpenSSH, while lacking those string functions, at least as far as the system library is concerned. In any case, what I mean by portable in this context, is standardized. strlcpy() and friends are not in any standard of which I’m aware, whereas strcpy() is in C and POSIX. And, as I already pointed out, there are contexts in which strcpy() is clearly a better choice over strlcpy(), in which case the link warnings are nothing but noise.

Security has nothing to do with what happens after a system has been compromised, period, security is in preventing the problem in the first place. If someone has already gotten into your system and planted a binary on it, then they can easily add to your $PATH. Security is containment and prevention, not random stupidity.

This statement is broken in so many ways it’s hard to know where to start. In the first place, you seem to be implicitly saying that all users on an OpenBSD have to be trusted users, which is a pretty silly thing to expect. In the second place, just because someone manages to get access to an unprivileged account, doesn’t mean you should make it easier for per to get access to a privileged one. And the “then they can easily add to your $PATH” is a complete non-sequitur, to say the least. We are, after all, talking about binaries in public locations, such as /tmp.

if every single bug ever was declared a security vulnerability

That is not relevant to the point. Nobody is talking about every single bug, we’re talking about DoS vulnerabilites. Everyone else in the world, except the OpenBSD folks, consider susceptability to DoS to be a security issue. OpenBSD does not get to redefine the term for themselves, in order to decrease the number of such vulnerabilities.

Security is not the difference between a “breach” and “system going down”. Security is security. I do not consider any machine that will die upon receiving a crafted packet to be “secure”, and neither does most of the rest of the world. It is indeed good that the user can’t trash the data; that doesn’t make it suddenly not an issue of security at all.

anything can be DOSed, period, there is no avoidance of it

Gosh, I guess we’d better tremble then: them terr’rists can simply bring down the entire interweb on a whim!

…But hey, I knew what I was getting myself into when I attacked people’s precious belief in OpenBSD as an ultra-secure operating system. And I’m not saying it’s not pretty secure: it clearly is. It’s just not as secure as it presents itself as being, and a certain amount of deception is involved in the claim.

The largest of your errors is OpenSSL, which is developed by OpenSSL, not OpenBSD. OpenBSD makes OpenSSH, and OpenSSH uses OpenSSL (as does OpenBSD), but the two development teams are unrelated to each other. OpenBSD developers have sent code upstream to OpenSSL developers, but there is no OpenSSL developer which is also an OpenBSD developer. OpenSSL is based on SSLeay, an older SSL implementation and has a licence that is markedly more restrictive than that which is used by the OpenBSD developers, in fact, that restrictive licence is why OpenSSL isn’t used with GNU programmes, because it has restrictions which the GPL does not.

OpenSSH isn’t just prominent on Unix systems, it’s inside many non-unix command line operating systems, including the Cisco IOS.

Another misconception is the OpenBSD string function set, not only are they portable, any operating system with OpenSSH on them has the set. The only C libaries which don’t have the OpenBSD-originated functions are the glibc’s and the Windows c libraries, other operating systems have them, but the maintainers of the GNU library have a strong dislike of OpenBSD. So no, they are portable functions, they’re even under BSD terms, it’s just that Ulrich Drepper is a twat that thinks everyone should use memcpy instead.

Security has nothing to do with what happens after a system has been compromised, period, security is in preventing the problem in the first place. If someone has already gotten into your system and planted a binary on it, then they can easily add to your $PATH. Security is containment and prevention, not random stupidity.

Your third hand discussion of the vulnerability by Core Security is silly to say the least, if every single bug ever was declared a security vulnerability, it would take away all meaning of the term, and if every time a bug was found, developers spent the month that Core Security’s people spent finding the exploit instead of just fixing it, nothing would ever improve in the system. A bug was found, it was fixed, Core Security insisted it was more important than a reliability issue, OpenBSD developers said they didn’t see the exploitability and moved on, Core Security then spent a huge amount of time finding an exploit for it, during which time a fair bit of change happened in OpenBSD, if OpenBSD used it’s resources like Core Security did, the system would run in the same fashion as OpenBSD 2.6 did. And indeed, a denial of service is no vulnerability, anything can be DOSed, period, there is no avoidance of it, a DOS does not break a system, it takes it down, the data on that system remains in tact and thus there is an inconvenience, but not a breach. Mitigation of a DOS does not prevent DOSes, nothing can, if someone wants to DOS, it is very easy to do.

If you read through the ports patchsets you’ll find a significant amount of work is required to make such Linux-centric software work on other operating systems, it is better to use the ports system than to try and roll your own in almost all cases.