OpenBSD 7.0 Released (openbsd.org) 56
ArchieBunker writes: Everyone's favorite security-focused operating system, OpenBSD, released version 7.0 today. In addition to the usual bug fixes and performance enhancements, support for RISC-V processors has been added. The changelog and mirrors can be found at their respective links.
RISC-V (Score:3)
This is really great, RISC-V is the future of embedded!
Came here for this (Score:2)
Re: (Score:2)
I'm so proud :'-)
Re: (Score:2)
Sure. It only needs to actually be functionally complete, get companies with actual money behind it, have proper application support, and then unseat ARM. Let's just say I won't hold my breath. Not that I am not excited at the prospect. I'm just really really skeptical.
Re: (Score:2)
Yeah, but you're an idiot who doesn't know any of those answers.
I'm a firmware engineer with multiple RISC-V processors on my workbench, all manufactured with real money.
"Functionally complete? WTF are you even talking about? It is a CPU instruction set. It is insanely complete.
No, don't hold your breath; none of this makes any difference to you. The products made will work exactly the same as if they had an ARM instruction set.
Re: (Score:2)
"Functionally complete? WTF are you even talking about? It is a CPU instruction set. It is insanely complete.
I know, that's why I can buy so many of them right now. ... oh wait they are still on your workbench.
Wake me when RISC-V matters, at the moment I'm happier being called an idiot than to be a delusional fanboi.
Everyone's favorite security-focused OS? Nope (Score:3)
I won't take away from all the good OpenBSD have done, giving us OpenSSH and maintaining it, auditing several popular OSS projects etc, but the security is largely overhyped.
Back in the day they used to coast on the secure by default nonsense (yes, disabling unnecessary services is good practice, but that's it), and yet they have always been resistant to adding things like mandatory and role based access controls
I'll take a properly configured SELinux installation over OpenBSD any day of the week.
With the latter, if someone gets root, you're still fscked. With the former, you can give the root password away all you like and it won't matter (assuming the setup is properly configured).
Re: (Score:3)
a properly configured SELinux installation
Welp, now you see the problem difference, none of it is ever properly configured until you do it... and even then you may have missed something.
Re: (Score:2)
Except it isn't that hard, and if you think it is there are simpler alternatives available, like AppArmor.
And even with having missed something, it's still superior to not having any form of that protection in place at all.
Re: (Score:2)
Except it isn't that hard,
Except that it is.
When you really want to lock your box down, it is far from easy. I've writen SELinux policies from the very early days, and I can't count how many times I locked myself out of the box so completely that only a hard reboot got me back in.
What most people do is not go down into the risky undergrowth. They exclude a few things they consider bad and think they're done. That's now what SELinux is about. If you want to really secure, you prohibit everything and allow only what's needed. And if y
Re: (Score:2)
Nope. It flat out isn't that hard. It takes effort, but it isn't that hard to understand. And really it only has to be done once, initially.
People are lazy. There are plenty of help and guides out there.
And anyway, I said this in another comment to you, but my argument was not specific to SELinux. That is just one instance of that type of project, there are others.
Re:Everyone's favorite security-focused OS? Nope (Score:5, Interesting)
Nope. It flat out isn't that hard. It takes effort, but it isn't that hard to understand. And really it only has to be done once, initially.
For the core system. Until a dist-upgrade.
It also has to be done for each service you run on the machine. And checked and updated whenever they update, because you never know if they decided that they need to do something differently than before in this patch - something your policy doesn't allow. Since SELinux breaks POSIX compatability (shouts to Theo, we discussed that question once) the service may not catch and log this properly and just crash hard and then you're there hunting for what throws it off, tracing syscalls.
People aren't just lazy. Most admins don't understand their system at the low level that writing a security policy requires. Do you know which syscalls Apache needs? Do you have a complete list of all files, including temp files, sockets, etc. that your Atlassian apps want to read or write (and do you know for each if they need read, write or both?) ?
The "lazy" part is what the current security policies are, which basically boil down to sandboxing ("here, that's your directory, inside of it I'll just let you do whatever because I can't be arsed to figure out what exactly it is you're doing there.")
In practical terms, I would recommend most people to stuff services into a sandbox over bothering with SELinux policies. This is where Docker and VMs become a security feature. Not because it's more secure (it's not), but because it's more practical.
Re: (Score:2)
You're really going out of your way to be pedantic here.
The problems you are listing are not real problems.
Yes, people are lazy. Yes, it takes some effort to set it up. No, policies don't have to change drastically between upgrades.
It's also bizarre to me that you claim 20 years in the infosec industry (which is my experience also) and you would recommend Docker or VMs over a MAC solution, when really you should be recommending both since they are not mutually exclusive.
And yet again, you are focusing very
Re: (Score:2)
I'm not recommending Docker, I'm saying that stuffing things into a box of whatever kind is an easy solution that most admins can actually manage, compare to extensive policy design that most admins can't.
The security that is actually implemented on the system matters. Not the theoretical level possible according to an academic paper.
I focus on SELinux because I know that one very well. Much of what I say applies to similar solutions as well, but I can't speak about the technical details of them, so I don't
Re: (Score:2)
Do you know which syscalls Apache needs? Do you have a complete list of all files, including temp files, sockets, etc. that your Atlassian apps want to read or write (and do you know for each if they need read, write or both?) ?
This sounds like something that you might be able to trace in a testing environment.
Re: (Score:2)
This sounds like something that you might be able to trace in a testing environment.
For the basic operation, absolutely.
But can you be sure that you trace all code paths? What about functions that are rarely used? How much testing do you want to do until you are reasonably sure that it won't suddenly freeze up in production?
In fact, this is how we used to write the basic policies (not sure how people do it today, it's been some years). We'd run the system in permissive mode, log the violations, and then there was a nifty script to turn those into a policy. SIEM systems follow the same prin
Re: (Score:2)
Just that in a SIEM system your anomaly will trigger an alarm and someone can look at it and say "nah, that's just a rare event we didn't see before." - in an RBAC/MAC system the kernel will deny access and your program may or may not handle that properly.
Only if it's configured that way. Rules can be relaxed to balance security and failure and the provided protection is still superior to a system without it.
This isn't complicated.
Re: (Score:2)
It absolutely is. It's trivial to set up a VM and monitor the behavior of the programs you need to write a policy for.
Pretty sure Tom just wants to be contrarian at this point.
Re: (Score:2)
You might say this is a fallacy because other ACL technology exists that wasn't created by NSA but you really have to wonder why this stuff exists and who uses it. Plus it doesn't scale to all use cases. Are you going to apply ACL to every node (IOT, whatever) that exists or are you going to build it off something l
Re: (Score:2)
OpenBSD lacking MAC or RBAC is a flaw as long as they want to continue to claim to be a security focused OS.
No, that technology doesn't have to be on every single network appliance, it's enough to have it on servers.
That even Windows has a form of MAC supports my point.
Re: (Score:2)
Given all the security breaches there have been and all the silly mistakes made that led to those breaches, my rule of thumb is that anybody who says "it's really not that hard" doesn't understand security.
Weasel Words: "properly configured" (Score:5, Interesting)
I'll take a properly configured SELinux installation over OpenBSD any day of the week.
This sounds so similar to what Windows advocates say, using weasel words like "properly configured" to deflect. The point of OpenBSD is that out-of-the-box, as-installed, it is well secured. Further configuration is only needed for things you enable.
Re: (Score:2)
lol, what nonsense.
"properly configured" is not "weasel words", it's a simple quantifier.
Secure out of the box is meaningless. Sure, it's "secure" to have a box with 0 listening services, it's also useless. Once you enable something, guess what? It has to be "properly configured" to be secure.
Re: (Score:2)
Re: (Score:2)
openbsd has no services
How long are people going to keep lying? It's UNIX. It has almost every unix service that you can ask for. It has superior and secure network services. No one is saying it has everything but to say it doesn't provide secure unix services is just disengenous lying. Its basically a swiss army knife of network engineering tools for free.
Re: (Score:2)
Stop being dense. I'm clearly not saying it doesn't provide any services.
Re: (Score:2)
Well, all base services run in a sandbox by default. Plus Firefox (chrome to I think) is also "sandboxed" by using unveil(2) and pledge(2). Plus this method adds no overhead unlike flatpak, snap, selinux and whatever other such things exist on Linux.
You can change Firefox settings using files in /etc/firefox-esr/ to adjust, far easier than selinux. I even doubt you can get Firefox secured in the same manner via selinux as one can in OpenBSD and have a full experience.
As time goes on, pledge/unveil is bei
Re: (Score:2)
Re: (Score:2)
Have you ever actually tried to administer an SELinux system? The system for altering rules is so byzantine that Red Hat won't actually support RHEL installs with custom rules (https://access.redhat.com/support/offerings/production/soc/).
The universal solution to "allow user X access to resource Y" seems to be audit2allow, but since every regular user runs in the same context, the rules it produces are essentially "chmod 777". I'm sure some madman out there has a "correctly configured" instance, but for 99%
Re: (Score:3)
I'll take a properly configured SELinux installation over OpenBSD any day of the week.
You'll have to show me that properly configured SELinux installation first.
I know what I'm talking about, my name is on the NSA's SELinux page and I've toured the world as an SELinux advocate in its early days. I still absolutely love what SELinux does and how powerful it is.
It's just that managing SELinux policies is far from trivial and few people have both the expertise and the time to actually do it, and the policies that ship with packages (if they ship policies) are very permissive.
Re: (Score:3)
Properly configured SELinux boxes are not at all hard to find - plenty of people have them setup and there are guides and info for how to do it properly. I haven't used RHEL in a minute but I understand these days the base configuration is pretty much done out of the box for packages that ship with the distro.
If you know what you're talking about and contributed to the project, then you are probably familiar with, if I'm remembering his name right, Russel Coker? Used to give lectures on SELinux and have pro
Re:Everyone's favorite security-focused OS? Nope (Score:4, Interesting)
Give my greetings to Russel. We did a couple things together back in the days, though I met him only once IRL, Australia being literally on the other side of the planet from Europe.
The funny thing is that "properly configured" is actually easier with OpenBSD than with SELinux (or systemd's sandbox features, or RSBAC, etc. - I know the RSBAC guy, had a nice long conversation with him after we both talked about "our" systems at Cebit). SELinux (and these others) are more powerful in that they go down to the syscall level and reside on Ring 0, but OpenBSD is definitely easier to configure properly and is quite tough when done so.
SELinux is what I would choose if the conditions are that there are users on the system. For a typical system these days, where you have only admin users on the system and everyone else accesses some web app or other service, OpenBSD is quite solid, especially if you set up your security levels.
I know that you CAN configure an SELinux system tight. I know Russel's play machines and I set up my own as well. I went to conferences and literally gave people the IP and root password to my machine (with ssh and remote root login enabled) - the same notebook I'd use during the speech, and nobody ever managed to disturb my presentation in any way. It's a fun party trick.
But your average Linux admin is not able to write a security policy. He will turn on SELinux and rely on the policies that ship with the distribution (Red Hat has done a lot in this regard, I met with a bunch of their guys in Tokio and talked about SELinux, maybe I've had a small part in it, but they already were interested in SELinux before, which is why they invited me in the first place). The problem with the distribution supplied policies is that they are very conservative, in order to not cause any trouble. It's better than nothing, but it falls far, far short of what SELinux could do in the hands of someone who can actually write a custom policy.
It's a knowledge problem, it's not a tech problem.
Re: (Score:3)
What point are you making by saying OpenBSD is easier to configure?
That has nothing to do with my point that it lacks a particular technology.
And since you're familiar with Russel's machines and setup your own, it makes your earlier statement asking to see properly configured machiens seem disingenuous, since you already knew where to find them and setup some yourself.
And now you're talking about how your average admin can't write a policy? So fucking what? They can learn, or the policy language can be impr
So SELinux is an unrealized aspiration (Score:2)
And now you're talking about how your average admin can't write a policy? So fucking what? They can learn ... Nothing you've said in any of your comments has negated the overall point I made in mine.
Actually you have done a wonderful job of discrediting, negating, much of what you said in this thread and elsewhere. If average linux sysadmins can't configure SELinux properly then your "properly configured" qualifier is simply nonsense, misleading to the point of falsehood as it is apparently not a reasonably attainable goal. Its nothing more than an unrealized aspiration for most admins.
Well done, thank you for making this reality clear.
Re: (Score:2)
Actually you have done a wonderful job of discrediting, negating, much of what you said in this thread and elsewhere. If average linux sysadmins can't configure SELinux properly then your "properly configured" qualifier is simply nonsense
1. This isn't about SELInux, there are other implementations
2. I haven't negated anything and sysadmins can certainly learn to configre SELinux. If anyone is negating themselves I would say it's 'Tom'.
Re: (Score:2)
I haven't negated anything and sysadmins can certainly learn to configre SELinux.
The point made about OpenBSD was highly secure as a default installation. You suggested SELinux was equivalent but later conceded that post installation configuration was needed and that many Linux admins are not qualified.
Re: (Score:2)
I made the point that OpenBSD is secure by default because it pretty much has everything idsabled. Despite the ill-informed user above saying 'properly configured' constitutes 'weasel words', OpenBSD would indeed need to be configured in whatever capacity it was going to serve as a server. FOr this reason I think bringing up the default install is rather useless.
I didn't suggest, I asserted SELinux and similar systems are *superior*, because they remove a single point of failure and allow far more granulari
Re: (Score:2)
I made the point that OpenBSD is secure by default because it pretty much has everything idsabled. Despite the ill-informed user above saying 'properly configured' constitutes 'weasel words',
Your admission that most Linux admins could not properly secure SELinux but could be trained actually proves your "properly configured" statement was in fact weasel words defined to portray the false image of equivalence.
OpenBSD would indeed need to be configured in whatever capacity it was going to serve as a server.
As would SE Linux, which unlike OpenBSD needs its base functionality configured as well. Again, your attempt to conflate the two is erroneous.
Re: (Score:2)
What point are you making by saying OpenBSD is easier to configure?
I'm making the point that "shipped is better than perfect". That you can theoretically harden an SELinux system much stronger than OpenBSD isn't worth anything if it remains theoretical because none of your admins can actually do it.
And since you're familiar with Russel's machines and setup your own, it makes your earlier statement asking to see properly configured machiens seem disingenuous, since you already knew where to find them and setup some yourself.
These were play machines. Not enterprise systems running actual production tasks. Nothing depended on them, there were no business restrictions and requirements. That's a huge difference.
They can learn, or the policy language can be improved to be more intuitive.
Have you written SELinux policies? Please try it before making such a statement. The policy
Re: (Score:2)
Alright, replying in parts since I don't have time to deal with /.s useless filters
I'm making the point that "shipped is better than perfect". That you can theoretically harden an SELinux system much stronger than OpenBSD isn't worth anything if it remains theoretical because none of your admins can actually do it.
That's not a point that needs to be made and has no bearing on any of the points I raised. It's just noise. Please try to keep track of the actual discussion.
Re: (Score:2)
Second part:
These were play machines. Not enterprise systems running actual production tasks. Nothing depended on them, there were no business restrictions and requirements. That's a huge difference
No, it's not a huge difference. The point is that machines can be properly configured, and you damn well know they can.
Your actual complaint is nothing more than saying "but some people find it difficult wahh!!"
Have you written SELinux policies? Please try it before making such a statement. The policy language has already improved tons since the early days, but this squarely falls into the domain of a problem that simply is hard by its nature and no amount of improvement will ever make it not a hard problem.
Yes, I have. And here again you seem to be wanting to just boast instead of actually making an argument.
For fucks sake. My point, for the nth time, was not even specific to SELInux.
The bad thing is apps running as root.
Yeah, that's what I said.
OpenBSD has done more than any other system to make priviledge separation a thing, exactly in order to solve that problem.
No, not really. They modified a few key commonly used programs. You know what reall
Systrace? (Score:5, Interesting)
Respectfully, you're about a decade out of date with your Systrace reference. It was replaced by pledge and unveil, both of which accomplish many of the same things, but in a way that is easier to configure. SELinux has many features that OpenBSD does not with pledge and unveil, but from a practical standpoint, both pledge and unveil are much easier to use.
I write services that run on Linux, FreeBSD, OpenBSD, NetBSD, seL4, etc. There are frameworks on each that can be used to lock things down. In practice, both pledge and unveil under OpenBSD are quite useful.
Re: (Score:2)
I didn't think it was a decade, but damn, OK. I agree with everything you've said, but if OpenBSD wants to keep promoting themselves as security focused, I think they should have more than just pledge and unveil.
Re: Everyone's favorite security-focused OS? Nope (Score:2)
Nonetheless, as an admin (at hobby level) for whom the SE-Linux configuration would be too much hassle, I'd imagine that an Android alike handling could be helpful, perhaps not in the interactive sense of pop-up lists, but overview lists of services with granted and denied requests, plus timestamps whe
Re: (Score:3)
A typical policy for a single service has hundreds of lines, some well over a thousand. It's not something you can hand-tune without a deep understanding of your system.
For the hobby or small enterprise level, the default policies that ship with some distributions (RedHat, Debian optionally, etc.) are in the "better than nothing" category.
Then again, mostly you need to stay up-to-date with patches, disable not needed services and not be an idiot when it comes to choosing your passwords. That should take car
Re: Everyone's favorite security-focused OS? Nope (Score:2)
Or, for the Dutch, how many locks are needed on a bike? As many as the nicer looking bike next to it, or alternatively, one more than the shabbier looking bike n
Re: (Score:2)
There's some truth to that, but there's the other aspect:
The largest volume of attacks is automated, low-effort attacks. Here it doesn't matter if someone else is weaker - if you are vulnerable to whatever exploit they are using, you're done.
That's why keeping up with security patches is probably the #1 thing to worry about.
But does it have systemd yet? (Score:2)
If you can learn how to install it (Score:1)
I have often heard that OpenBSD is slow (Score:2)
I used FreeBSD as my default desktop for about two years. I liked everything about FreeBSD, except the lack of apps. In that respect, FreeBSD lagged behind Linux.
I have always heard that OpenBSD was slow. This seems counter-intuitive to me. My understanding is: OpenBSD team will remove code as often as the add code. Therefor OpenBSD is a leaner system.
Re: (Score:3)
There is a 10% to 20% performance hit over Linux / FreeBSD. But, the OpenBSD developers have worked hard to tighten this. With each release, it gets faster relative to other distros. The developers have purposefully disabled many features by default that can enhance performance, such as SMP. These can be turned back on if you are willing to accept the risks. For instance, with SMP, there are still potential branch prediction risks (e.g. similar to Spectre / Meltdown). The OpenBSD developers focus on c
If only it were standard at Water Treatment Plants (Score:2)
Funny to see this as a small story (because so few users) near the story on the ramping-up attacks on Water Treatment Plants.
The WTP mainly need more due-diligence on a total airgap, of course, but they also could be demanding control software that didn't run on Windows. Yes, Windows is a popular platform for plant control software. Insane.