FreeBSD security design flaws

loveydovey

loveydovey

Anthropic's model believes FreeBSD has ways to go. Get working!
FreeBSD's Biggest Design Problems from a Security Perspective
FreeBSD is a solid, well-engineered OS, but its security limitations are largely inherited from its Unix heritage — design decisions made in the 1970s that were never meant to withstand modern threat models.

1. The Ambient Authority / DAC Model (The Core Problem)​

This is arguably the root of everything else. FreeBSD uses Discretionary Access Control (DAC) — the classic Unix user/group/other permission model. The fundamental flaw:
  • Permissions are attached to users, not capabilities
  • Any process running as a user inherits all of that user's rights
  • root is a god-mode binary switch — you either have it or you don't
  • A compromised process gets the full authority of whoever launched it
A ground-up fix would mean replacing DAC with a capability-based security model (like seL4, Fuchsia's Zircon, or CHERI's hardware capabilities), where processes hold only explicit, unforgeable tokens for the specific resources they need. FreeBSD actually has experimental CHERI support (CheriBSD), but it's not the default or even close to mainstream.

2. Monolithic Kernel​

FreeBSD runs device drivers, filesystems, and networking stacks in kernel space. A bug in any driver is a bug with full ring-0 privilege. This means:
  • A vulnerability in a rarely-used USB driver can compromise the entire system
  • The kernel's attack surface is enormous
  • Memory corruption in one subsystem can affect everything
The fix would be a microkernel or hybrid architecture (like Minix 3, QNX, or Fuchsia) where drivers run in isolated userspace processes. A crashing or exploited driver crashes only itself.

3. No Mandatory Integrity/Label Model by Default​

FreeBSD has MAC framework (Mandatory Access Control) and TrustedBSD hooks that can enforce label-based policies, but:
  • It ships disabled by default
  • Configuration is complex and rarely used in practice
  • The labels system doesn't extend cleanly to the network stack
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.

4. The setuid/setgid Mechanism​

FreeBSD inherits the deeply flawed setuid bit — a file-level flag that says "run this binary as its owner, not the caller." Problems:
  • Any bug in a setuid binary is a privilege escalation vulnerability
  • The attack surface has existed for 50 years and keeps producing CVEs (sudo, pkexec, etc.)
  • There's no sandboxing of what a setuid binary can actually do
A proper fix requires fine-grained privilege delegation — no program should need to run as root just to bind a port or write a log. FreeBSD's capsicum(4) framework is a good step here, but adoption is limited.

5. Capsicum Exists But Isn't Ubiquitous​

Capsicum is actually FreeBSD's best security innovation — a capability-based sandboxing model that restricts what an already-running process can do. It's elegant. The problem:
  • Developers must opt in manually with cap_enter()
  • Almost no third-party software uses it
  • It's not enforced on system utilities by default
A ground-up redesign would invert this — every process starts in capability mode and must be explicitly granted ambient authority, not the other way around.

6. Memory Safety in the Kernel (C all the way down)​

The entire kernel is written in C, which means:
  • Buffer overflows, use-after-frees, and type confusion bugs are structurally possible at every line
  • No compile-time enforcement of ownership or lifetime rules
The fix is a kernel rewritten in a memory-safe language — Rust being the most realistic candidate today. Linux has started down this road; FreeBSD has not made a serious commitment.

7. Network Stack: No Default Cryptographic Identity​

Processes can bind to arbitrary ports. There's no kernel-enforced notion of which program is allowed to listen on what, no cryptographic attestation of service identity, and spoofing mitigations (like strict reverse-path filtering) are opt-in.
A modern redesign would build service identity into the network stack — closer to what Plan 9 attempted, or what WireGuard does at the VPN layer, but applied universally.

Summary Table​

ProblemRoot CauseIdeal Fix
Over-privileged processesAmbient authority / DACCapability-based OS model
Kernel driver exploitsMonolithic kernelMicrokernel / driver isolation
No mandatory integrityMAC off by defaultBake in Biba/Bell-LaPadula
setuid attack surfaceUnix legacyFine-grained privilege tokens
C memory unsafetyLanguage choiceRust kernel components
No process sandboxing by defaultCapsicum opt-inCapability mode by default

The Honest Bottom Line​

CheriBSD (CHERI + FreeBSD, from Cambridge/SRI) is probably the most serious real-world attempt to address the deepest problem — ambient authority — by using hardware-enforced capabilities in the CHERI ISA. If that work were combined with a Rust kernel, Capsicum-by-default, and mandatory integrity labels, you'd have something genuinely novel. But it would essentially be a new OS that resembles FreeBSD, not FreeBSD itself.
 
Great more AI bullshit, I wonder why having a full AI written post could be allowed in this forums in the first place.

Really funny that it talks about setgid thingies when we do have a mac based non setgid sudo alternative that is called mdo that is shipped in 15.0. So as always just spreading fud.

As for capsicum, the AI didn't understand the philosophy. The point is to secure trusted code like the one in base, basically dropping privilege to any stuff.

As for not using root for binding on lower port, it is already done, see ntpd there is a freaking mac policy for that.

So to sum up, just some AI slop as always.
 
Its pretty clear that OP is here only for trolling. None of his posts are making any sense. He is doing this so subtly to avoid moderator action.
 
To show an example of how AI can't be trusted:
6. Memory Safety in the Kernel (C all the way down)
The entire kernel is written in C, which means:
Buffer overflows, use-after-frees, and type confusion bugs are structurally possible at every line
No compile-time enforcement of ownership or lifetime rules
The fix is a kernel rewritten in a memory-safe language — Rust being the most realistic candidate today. Linux has started down this road; FreeBSD has not made a serious commitment.
Click to expand...
Most major OS kernels are written primarily in C: Linux, the BSDs (FreeBSD, OpenBSD, NetBSD), Windows NT kernel (C with some C++), XNU (Darwin/macOS, a mix of C and C++)
 
  1. Capability-based controls that legacy model (+ACL) cannot do should be done by hardware (not even firmware) level like in mainframes. Cheri should be the bare-minimum. Same interface, but different implementations per chip manufacturers should be mandatory not to be passed through even one implementation is cracked.
  2. So why Unix-derived OS? Reimplement as different OS.
  3. It's on admins. OS should keep compatibilities by default and allow stricter model per configuration or fork (like HardenedBSD does!).
  4. It's needed for backward compatibilities. And if I recall correctly, executables having such attributes are decreasing in base.
  5. Capsicumizing is on the way. An example here.
  6. Memory safety is NOT purely depends on languages. If understanding Turing-complete right, all Turing-complete languages are memory-unsafe, as they can describe memory unsafe programs.
  7. It should be on policies of admins.
 
LLMs don't have opinions, they will relentlessly argue in defense of whatever point that you ask them. Anyway, if you want a particular result, send patches or go generate your own operating system.
 
drhowarddrfine said:
Most major OS kernels are written primarily in C: Linux, the BSDs (FreeBSD, OpenBSD, NetBSD), Windows NT kernel (C with some C++), XNU (Darwin/macOS, a mix of C and C++)
Click to expand...

drhowarddrfine said:
CShell I don't think so, so let's not go there.
Click to expand...

As you pointed out yourself....

I don't mind BALANCED articles where something is completely thought out -- but (this post) basically ignores decades of computer science.
 
Here, another "point of view", also AI generated blablabla, of course:

Rich (BB code): 
FreeBSD is considered very secure for several practical reasons:

    Conservative development model
        Single, integrated base system (kernel + userland) maintained together, reducing integration bugs.
        Peer review and long-term stability focus produce fewer regressions.

    Small default attack surface
        Minimal services enabled by default; clean default configuration reduces exposure.

    Strong isolation and sandboxing primitives
        Jails: light-weight OS-level isolation for services.
        Capsicum: fine-grained capability-based sandboxing.
        Securelevels and kernel-enforced restrictions via TrustedBSD/mandatory access control (mac) framework.

    Advanced security features
        Mandatory Access Control (multiple MAC modules).
        Geli and GEOM for disk encryption and integrity.
        Hardened memory protections and runtime mitigations (ASLR, W^X where applicable).

    Fast, focused security response and tooling
        Dedicated security team issuing advisories and patches.
        Easy auditing: cohesive codebase, comprehensive manpages and Handbook.

    Predictability and performance under load
        Deterministic behavior and resource controls reduce risks from resource-exhaustion attacks.

    Licensing and transparency
        Permissive BSD license and complete base system encourage inspection and third‑party review.

Caveat: actual security depends on configuration, patching, and operator practices; an insecurely configured FreeBSD can be compromised like any OS.

I wish this posting of AI crap would stop. It's completely pointless to even start any discussion about that junk!
 
Having access tp all bytes because it's your computer isn't "memory unsafe" but a functionality. It's called RAM for a reason.
Root can overwrite the kernel runtime code and crash the machine. It's a normal thing.
 
I believe that FreeBSD is more secure than linux because it opens less attack surface. Linux is moving fast, opening more interfaces, more possibilities each day. I think also that to be less used is an advantage.

The thing that bother me in this thread is to relie on IA to detect security weaknesses where one cannot do on itself. I mean, the FreeBSD security staff already know that either from their own knowledge or by asking to an IA.

So, probably nothing new here. Another useless thread. There are already many yet.
 
Emrion said:
I believe that FreeBSD is more secure than linux
Click to expand...
100%. Not only that but FreeBSD is also "easier" to secure.

This is not a useless thread. AI had been instrumental in me getting up and running on FreeBSD after Linux. It might be useful to summarize the state of development of FreeBSD's security. I am seeing lots of new CVEs, so it's not like it's not a valid thought vector.
 
T-Aoki said:
  1. Memory safety is NOT purely depends on languages. If understanding Turing-complete right, all Turing-complete languages are memory-unsafe, as they can describe memory unsafe programs
Click to expand...
Eh YES and NO, but more NO than YES.

NO because Turing Completeness assure you that you can use a memory safe programming language (PL) for solving all problems that can be solved from an unsafe PL. Maybe you cannot use some low level optimizations in the code, or some clever algo, because the type checker does not allow them, but you can still solve the problem, using some memory safe algorithm. For example a Turing Machine is Turing-complete, but you cannot code an optimized vectorial version of the algo, or use effcient pointers. You had to use inefficient algorithms, but the problem can still be solved. In this case is the Minimum-Viable-Hardware that can solve the problem.

NO because, in safe languages if the compiler tell you that there are no certain types of errors, then you are sure that there are no these erros. Maybe it can refuse to accept correct algo, because it cannot be sure that they are correct, but if the compiler tell you that it is ok, then it is for sure ok.

YES because if you use a memory safe language as an interpreter or compiler of a memory unsafe one, and you execute in it an algo written for the unsafe language, then you can experiment all errors of the unsafe language, but in the virtual memory addresses you are emulating. In other words: the interpreter or compiler will not have memory errors, during their interpretation or compilation phase, but the executed code can contain memory errors in its emulated memory. But usually this bypass is rather explicit. It is like executing a "sudo ..." in a script.
 
Point #2 is dumb.
Monolithic Kernel is preferred for wide hardware support.
If you want to build a microkernel for your FreeBSD hardware it is not hard. It just takes common sense. Do you need a floppy disk driver in your kernel?
Very flexible system we have. It does take knowledge..
 
OpenFreeNet said:
Eh YES and NO, but more NO than YES.

NO because Turing Completeness assure you that you can use a memory safe programming language (PL) for solving all problems that can be solved from an unsafe PL. Maybe you cannot use some low level optimizations in the code, or some clever algo, because the type checker does not allow them, but you can still solve the problem, using some memory safe algorithm. For example a Turing Machine is Turing-complete, but you cannot code an optimized vectorial version of the algo, or use effcient pointers. You had to use inefficient algorithms, but the problem can still be solved. In this case is the Minimum-Viable-Hardware that can solve the problem.

NO because, in safe languages if the compiler tell you that there are no certain types of errors, then you are sure that there are no these erros. Maybe it can refuse to accept correct algo, because it cannot be sure that they are correct, but if the compiler tell you that it is ok, then it is for sure ok.

YES because if you use a memory safe language as an interpreter or compiler of a memory unsafe one, and you execute in it an algo written for the unsafe language, then you can experiment all errors of the unsafe language, but in the virtual memory addresses you are emulating. In other words: the interpreter or compiler will not have memory errors, during their interpretation or compilation phase, but the executed code can contain memory errors in its emulated memory. But usually this bypass is rather explicit. It is like executing a "sudo ..." in a script.
Click to expand...
My point is that "really memory safe" language mutually CANNOT write drivers for mutually memory unsafely designed devices (i.e., sharing input and output buffer as writable, that requires "volatile" in C, and it must be mapped on main memory, thus, DMA is used).

If the language has exceptions to support writing drivers for such mutually memory-unsafe devices (like UNSAFE blocks in Rust), the language CANNOT be called "memory safe".

And if I understand correctly, "Turing-complete" means "can write any program" regardless it's efficient or not. So really memory-safe language CANNOT be called "Turing-complete".
 
Phishfry said:
Point #2 is dumb.
Monolithic Kernel is preferred for wide hardware support.
If you want to build a microkernel for your FreeBSD hardware it is not hard. It just takes common sense. Do you need a floppy disk driver in your kernel?
Very flexible system we have. It does take knowledge..
Click to expand...
Yes. There's "MINIMAL" kernel config (works are under way, though).
And should note that the term "micro kernel" has quite wide varieties of definitions. mach, NT, MINIX, ...
 
T-Aoki said:
And if I understand correctly, "Turing-complete" means "can write any program" regardless it's efficient or not. So really memory-safe language CANNOT be called "Turing-complete".
Click to expand...
This is not correct. With a Turing Complete PL you can solve "any computable problem on it", but it is not mandatory that you can execute every algo/program on it. Turing Machines are Turing Complete but you cannot express every algo on it.

In many cases they prove this saying that you can emulate on a Turing Machine also a modern AMD64 CPU, and run every AMD64 assembly code on it. Every operation involving registers will search the value of the register on the tape. It will be exponentially slower. It will terminate some century after the real AMD64 CPU, but it will terminate with the same exact answer.

But what you are saying, can have some sense. You can have some particular problem that can be solved in an efficient way from an algo on a certain (unsafe) PL, but the same algo with the same or equivalent tricks cannot be expressed on a certain safe PL. Hence, the safe PL introduces some limitations. The trick is creating PL with reasonable limitations.
 
1781391614419.png
 
You must log in or register to reply here.
Back
Top