New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
I am neither exploited nor an exploiter and I couldn't care less about either, we live worlds apart.
Never had an issue with any of those strings you mention and I don't even know or care if they are real. Want to stay that way, they walk their side of the street and I walk mine.
I take my precautions, we don't meet.
They're not (all) blackhats. Cloak-and-dagger sure, but they walk on the right side for the most part.
Surely you've heard of grsecurity, the Linux patch? Now you might recognize two of them.
Anyway my point is just that you shouldn't hold up OpenBSD as if it shows anyone that exploit mitigation can be done well in C, since their exploit mitigations are pretty awful.
OpenBSD's way is simplicity, if you follow the rules of simplicity you'll be safe because you'll have a clear view and understand everything. You will not find many surprises on your way, unlike Linux.
Take the BCHS web development stack, try it in Linux and you may be at risk, do it in OpenBSD and you'll be safe.
Do Linuxy stuff in OpenBSD and you'll be in trouble real fast, stick to OpenBSD's way and you'll be safe.
People who say OpenBSD is unsafe are people who bring a Linux mindset not an OpenBSD mindset.
OpenBSD in much more limited and in many ways simpler than Linux, it is much slower, under the hood Linux operates very differently from OpenBSD, the same actions can have very different outcomes.
For someone who likes to have control and understand how everything works OpenBSD is great, just not fast or easy.
You can't use OpenBSD to do lots of the stuff you're doing easily using Linux.
Soon™️
We're thinking of it from different perspectives. OpenBSD gives you fewer opportunities to shoot yourself in the foot (which is awesome, don't get me wrong), but my perspective is from "take an unprivileged process and try to get kernel mode by interacting with the kernel's attack surface". For OpenBSD, meeting that goal and getting an LPE is significantly easier.
Now how many changes does it give you to try doing that, do you get many?
Depends on how fast the CPU is and how complex the exploit is. OpenBSD doesn't have anything like grsecurity's crash brute force protection, so unless the exploit requires setting up a really slow race condition, I'd say it gives you anywhere between several hundred and several hundred thousand chances per second.
Same with vanilla Linux btw, OpenBSD is not unique there.
Have you been successful?
Yes, with both OpenBSD and Linux. But it was part of training so I had substantial help. I'm no comex or pipacs.
I think OpenBSD' userland is top notch. Otto malloc is amazing. It even zeros on
free()! And it uses privilege separation and dropping everywhere, so evencat(1)has the OpenBSD equivalent of a seccomp filter! That's pretty awesome. But its kernel is meh. That's the only issue I have with it.I assume comex and pipacs are two high priests of your trade.
I don't believe there will be many people giving you or them access to low privilege processes on their systems. I certainly would not give access to any of you.
Well maybe I'd give you access to a passwordless restricted shell account, as a test, who knows.
Just experts in exploit development and mitigation. You know ASLR which is pretty much universal on all OSes now? The second guy invented it. If you don't care about exploit mitigation or don't hold security in high regard that's fine, but then you shouldn't opine about which systems can better resist exploits than other systems.
With that logic, why don't you just run everything as root and say screw defense in depth?
The whole point of defense in depth is to prevent some RCE against your NTP client or your DHCP client from giving an attacker kernel mode, or from an exploit in your browser's image parser from doing the same.
Maybe I should give you something to hack, then we'll see how you fare.
You seem to focus too much on technique and forget about the whole picture.
I never said I was good enough! Like I said, the only time I got an LPE on OpenBSD was as part of a class.
Most I could probably do is crash the kernel with memory corruption.
Not at all. I'm just contesting the very narrow claim regarding OpenBSD's security against exploits (which is surely what was meant by holding them up as an example of a secure system written in C rather than Rust, as that limits the discussion to memory-safety and undefined behavior-related exploitation).
I said a page ago that OpenBSD makes it much harder to shoot yourself in the foot, and that is an important part of the big picture. Its security defaults are quite good and it has an extremely locked-down userland.
Linux could use some of those security defaults and be simpler too but nah, Linux people these days hate simplicity, they love overcomplication and will rather put layer upon layer of Rube Goldberg contraptions to solve their problems.
As a result Linux became a complete mess and now they say they need rust to save them. My question is: who they gonna call to save them from rust?
Disagreed. If you write code that is inherently insecure to the point of 30+ CVE's, I have zero faith in your knowledge of properly designing storage architecture and the technologies that go along with it. If you can't do basic security, how can I trust that my data is safe with your storage solution?
minIO did dirty things, haven't used them since ,will give this try for sure
It's the fact that they're almost all high-severity that matters. 30+ CVEs, if they're mostly low-severity, just shows a very proactive security stance. But 30+ almost all with a CVSS score of at least 8 is not a good look, especially when it's not a particularly difficult job it has to do (compared with, say, a video decoder).
It would really be a shame if this project completely destroyed minio's business model.
And by shame I mean joyous rapture.
I remember this
Why does it have to be called RustFS? Talk about non-descriptive.
Its a object storage (S3 compatible) server. Not a filesystem. And the language its written in should not be its only unique feature.
Why are your Father & Mother name you the way you are right now?
Many reasons.
I don't know I just have a dislike for projects that are:
a) inaccurately named;
b) include the language of implementation in the name (unless its a library for that language e.g phpyaml would be fine)
The thing is it's just a name, and you can name whatever tf you want for your "products".
No your parent name you that because they liked that name.
33 CVEs, at least half of them are high and critical vulnerabilities.
Nah, I'm good with my Garage.
Garage isn't bad, I used it too.
so how is rustfs compared to https://github.com/pgsty/silo ?