FreeBSD security design flaws

And there's HardenedBSD, which (as far as I know and if I understand correctly) configures security features FreeBSD has activated as much as possible (minus anything depending on running hardware having specific feature or not that cannot make as defaults on releases) and adding some additional tools.

It's still (almost) FreeBSD (rebasing their repo with FreeBSD), but released as different downstream release as it should break backward compatibilities with previous releases of FreeBSD. And breaking backward compatibilities disallows FreeBSD project to switch to HardenedBSD's defaults.
 
I'm not fond how of HardenedBSD has splintered the community and potential resources for FreeBSD. They could've simply relegated to being a security patchkit for vanilla FreeBSD. (ie. grsecurity, Hardened Gentoo) With pkgbase, I see less reason for it.
 
rcbsdpge said:
So I have word back from one of the greybeards from the Reddit arm of the community. This is his advice and I will quote as originally advised:

“As someone whose been on the BSD community for decades, I’d advise you to take anything said by a greybeard with multiple grains of salt, when it comes to new developments. Most of them seem to be stuck in a time loop. In the past, there were greybeards who were also against these now common technologies:
Click to expand...

Uh, yeah?
And some greybeard somewhere on the internet told me:

'As someone whose part of BSD development since its dawn, I'd advice you to take anything said by a greenhorn with a lot of salt and caution, when it comes to development. Most of them seem to live in some fluffy pink candyfloss SciFi air castle, snatching unquestioned everything new there is just because it's new. Blindly trust and naive believe in all new things bring benefits only, just because they are new. Never experienced all things always also bring downsides. Nor people not telling the whole truth, often even lying ruthless. Never using new technologies for making the world a better place but abusing them greedy for just to make money only. Not seldom trying to sell the same old crappy junk over and over again for decades, only disguised as something new. And because the greenhorns do not seen it yet so far, they fall for it, believing it was something new, and so it must be done, because it's new, so better.
We greybeards already seen most of it and experienced all the shit it already caused, and the effort it took to clean up the mess afterwards again. We share our experience with the greenhorns not to repeat the same mistakes again and again. Not to fall blindly for anything presumptive new unquestioned and uncritically. For that we are named cavemen, preventing progress, stuck in the past or time loops, had no idea how the world works.

If all things were done only by greenhorn's ways, all we had today was a wild zoo of zillions fancy ideas, all started, none finished. An unreliable, unusable, not working chaos.
The kernel sources alone would consist of at least two dozens different languages. Impossible to maintain. Only new features were brought in. Bugs in old language's sources not fixed, because everybody refuses to learn those "ancient, obsolete" languages. Anything but reliably solid.
Documentation, if done at all, was only done on websites. Most of them 404 or obsolete, because nobody has access. No manpages delivered with the software, but everything depends on having always internet connection and servers randomly maintained by thirds.
If there were any BSD at all anymore, not drowned in a swamp of zillions of different forks. Single people left former teams mopey, because they fell their fancy ideas were not appreciated enough. So starting their own fork. But then stop somewhere on the way, when they realize it takes a lot more to bring a project to an usable, solid working state than just having fancy ideas. But alas their work power and competences are lost for the original project.'
 
Last edited:
What a pointless thread, because no OS is 100% safe by design on purpose. You always have to make tradeoffs for it to be usable and flexible enough.

If you really want to hear own researched meanings about it look at Ilja van Sprudel instead of Claude playing Captain Obvious.

@OP: Your "Get working!" is really disrespectful in a multitude of ways, because the consequence would be rewriting major parts of the OS. Alone using a LLM shows that you've got no clue what you are talking about.

Rewriting the kernel in Rust... hahaha NO!
 
CShell said:
But I don't remember if this idea actually went to production or not
Click to expand...
I never heard of that, but I highly doubt that such a chip was capable for the market.
I estimate the instruction set was extremely large and complex, so the chip became very large and expensive. And I wouldn't be surprised if it was a real juice sucker and very slow at the same time. And then it could run Java only, so being pretty incompatible to anything else?
I highly doubt such a thing would become a bestseller.
 
Maturin said:
I highly doubt such a thing would become a bestseller.
Click to expand...

Ah .. well Sun Microsystems was likely interested in licensing Java for hardware chip production :cool: . Imagine getting revenue (aka "paid") for each Java processor deployed to (each) customer.

At the time Windows/Intel (aka "WinTel") was making a lot of money in the market place and Sun was interested in getting Java-On-A-Chip to compete. They (were likely?) also thinking about "devices" at the time - aka Cell Phones, PADs, Tablets... but I do remember some discussion of having PC's run these chips as well.

Sun was already making SPARC chips (RISC) and so forth for their Sun manufactured Unix machines. (Link Wikipedia): Sun SPARC

You can read a little bit about this here: (Link Wikipedia): Java_processor
 
The greatest security factor is always human factor,although design of software also matters.To me the more centralized development model of FreeBSD (and other BSDs) is better at blocking supply chain attack,and allows better code quality.
 
CShell said:
Ah .. well Sun Microsystems was likely interested in licensing Java for hardware chip production :cool: . Imagine getting revenue (aka "paid") for each Java processor deployed to (each) customer.
Click to expand...
Everybody is always interested in everything, and thinks about it. 😎
That means nothing.
And of course you can make a lot of money with such a thing - if it sells. 🤓
CShell said:
Sun was already making SPARC chips (RISC) and so forth for their Sun manufactured Unix machines.
Click to expand...
Yeah, I'm fully aware of that.

Such are also always BA's decisions.
One MBA comes and says, 'we can make a lot more money, if we don't buy those parts, but produce them ourselves, because we don't need to pay other's revenue but keep it for ourselves.'
Then a couple of years later another MBA (sometimes even the same) say, 'We need to sell that branch of our business. We are saving more money and be more flexible when we do not produce those things ourselves but simply buy those parts on the market by competing companies.'
Then a couple of years later again it's, 'We better produce those things ourselves. Makes us more independent and gives us a bonus towards competitors. Also the collaboration between the different disciplines stay under the same roof...'
Then it needs to be sold again, 'we need to focus on our core business.'
etc, etc.

But RISC is quite the opposite of how I can imagine a processor executing an object oriented HOL directly.
Processor design always also is to find the right compromise for the size.
A more comprehendable instruction set means more complex things can be done with fewer lines of machine code, so less clock cycles and less memory.
In contrary a smaller instruction set means you need more machine commands to accomplish the same job, but it also means less circuits, less complex circuits, that keeps the die small. This means less size, less power consumption, less heat dissipation (mobile apps), less silicon needed, so less production cost. Plus fewer development effort. Plus commonly the chip can be clocked at higher frequencies, which in many cases comes at the end to more computation speed than saving code by using a more complex instruction set.

Those were my concerns. I never doubted such a thing was technically possible. I just doubt it could hit the market and become profitable.
 
hardworkingnewbie said:
Java CPUs were dead once JIT arrived. Also since the JVM was constantly changing CPUs would have always play the catch-on game.
Click to expand...
Speaking of JIT. So, FreeBSD has this W^X off feature, but JIT (in Firefox) bypasses it by dual-mapping or something. I don't understand how I can have W^X off in FreeBSD, but Firefox's JIT just bypassing that.
 
I'm more concerned about the exploit generators known as LLM being used to "fix" things. I guess they should be programmed to report "the fix is in" upon completion.

The-fix-is-in Definition & Meaning | YourDictionary

The-fix-is-in definition: (idiomatic) A process (for example, a court case) has been rigged behind the scenes and its outcome will not reflect true justice.
www.yourdictionary.com www.yourdictionary.com

An LLM is like a shady car repair shop. You get a report showing 20 more problems than when you brought it in. And, oh, by the way, it's gonna cost ya just a little bit more than the original estimate.

Edit: on topic song

View: https://youtu.be/cXH5Wy_8BbY?si=eAspPa_UQnQ50cFl
 
  • Like
Reactions: bjs
I would like to say a word about this:

A secure-by-default design would bake in something like Biba Integrity or Bell-LaPadula at the kernel level with no way to turn it off, so untrusted data can never flow upward to trusted processes.

In the ‘80s/‘90s, I shepherded a mainframe security product (ACF2) through an Orange Book B1 evaluation, which included MAC using Bell-LaPadula. I spent a year giving talks to customers about why MAC would be good for their business. The poster child was a company that accidentally sent the executive salary summery to a shop floor printer during Union negotiations.

The customers didn’t buy it, and they were right.

The military and the intelligence community use MAC because the consequences of accidentally leaking classified information is so great. (I once asked an evaluator why we were working so hard to protect the classified information, when the government kept hiring moles who leaked the information to our enemies. He said that we were protecting against Trojan horse programs that might leak data to lower levels and the the hiring of moles was an administrative problem that was outside the scope of the evaluation.)


Most editors keep a file of user preferences. With MAC, you have to login at your least-privileged level to update the preferences. If you are logged in at a high level and someone at a lower level sends you a message, you can’t reply, and the system probably can’t even mark it as read. If you are logged in at a high level, and you want to make yourself a note about something, if you want to be able to read it at a lower level, you have to take a picture of it and type it back in at the lower level.

These things make MAC almost unusable for general users. (If you have a highly structured situation, like a machine that only runs a multilevel messaging system, you can get it to work. But not for general purpose computing.)

One thing I would like to see implemented was informally called HAC. It was proposed by a guy named Harold, and I am sorry to say that I do not remember his last name or affiliation, and HAC stood for Harold’s Access Control.

The idea was that if you make a copy of a file, it keeps its original DAC restrictions, possibly further restricted by additional restrictions you put on the copy. Conceptually, it is like the ORCON (Originator Controlled) handling caveat used for classified information. Needless to say, it would be a pain to implement, especially dealing with cases like the originator deleting the original file: does this mean they wanted to delete it for everyone, or just that they were done with their copy?
 
astyle said:
All of OP's points can be easily rebuffed if you do a bit of homework and actual research.

Ever hear of Principle of Least Privilege? It basically means to give a user the minimum amount of permissions to still get the job done.

Also: FreeBSD does ship with a lot of things un-configured, you gotta configure the security yourself. But the funny thing about security is, if you just RTFM and set the security up with the basic safeguards, that will keep you out of trouble. FreeBSD actually has most of the same tools as OpenBSD, available in Ports.
Click to expand...
True, and I just learned how to use Google Authenticator as a second factor for ssh connections. On top of certs. It's not hard, but does require a small amount of effort. Not to mention the excellent jail infrastructure.
 
You must log in or register to reply here.
Back
Top