Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

hardenedbsd.org

Post reply on HN
Print view View original

21–30 of 81 posts

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#21

Post by ruthmarx »

yjftsjthsd-h wrote: post #18
ruthmarx wrote: post #17

Earlier quoted context omitted.

I thought that might be the case. So not actually sandboxing at all.

What does Sandboxing™ give you that pledge+unveil doesn't?

> Sandboxing™

Writing it like this is kind of funny, hoenstly, but not for the reasons you probably think.

> give you that pledge+unveil doesn't?

Not requiring the cooperation of developers to opt-in, for starters.

You really think pledge and unveil are equivalent to sandboxing? Can you refer to any sandboxing solution or technologies that limit themselves to restricting syscalls and hiding file paths? Unveil is a lot more useful as a component in sandboxing, I'll give you that.

Something like linux namespaces or even capabilities would be a hell of a lot better though.

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#22

Post by saagarjha »

brynet wrote: post #16

It's easy to invent a chart that only you can get a nearly perfect score on. This does nothing to explain what any of these features are, what are "Boot hardening" and "sysctl hardening"? At least OpenBSD's innovations page makes an attempt to explain new concepts and features that have been developed over the years, and people can make any comparisons for themselves. https://www.openbsd.org/innovations.html

I mean, both of these are really just lists of mitigations. What would really be useful is why each of these has been developed, what attacks it tries to stop, why that was chosen as something worth protecting against, and what is out of scope for each of them.

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#23

Post by ori_b »

ruthmarx wrote: post #21
yjftsjthsd-h wrote: post #18

Earlier quoted context omitted.

What does Sandboxing™ give you that pledge+unveil doesn't?

> Sandboxing™ Writing it like this is kind of funny, hoenstly, but not for the reasons you probably think. > give you that pledge+unveil doesn't? Not requiring the cooperation of developers to opt-in, for starters. You really think pledge and unveil are equivalent to sandboxing? Can you refer to any sandboxing solution or technologies that limit themselves to restricting syscalls and hiding file paths? Unveil is a lo…

Most programs require a setup phase, where they want a great deal of access to the environment to set up the resources they use, and a steady state phase, where they need very little access beyond pre-opened file descriptors.

An externally imposed sandboxing feature can be useful for namespacing, but is necessarily less restrictive than pledge and unveil. For example, in steady state on OpenBSD, most programs can't even their own configs.

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#24

Post by ruthmarx »

ori_b wrote: post #23
ruthmarx wrote: post #21

Earlier quoted context omitted.

> Sandboxing™ Writing it like this is kind of funny, hoenstly, but not for the reasons you probably think. > give you that pledge+unveil doesn't? Not requiring the cooperation of developers to opt-in, for starters. You really think pledge and unveil are equivalent to sandboxing? Can you refer to any sandboxing solution or technologies that limit themselves to restricting syscalls and hiding file paths? Unveil is a lo…

Most programs require a setup phase, where they want a great deal of access to the environment to set up the resources they use, and a steady state phase, where they need very little access beyond pre-opened file descriptors. An externally imposed sandboxing feature can be useful for namespacing, but is necessarily less restrictive than pledge and unveil. For example, in steady state on OpenBSD, most programs can't e…

> An externally imposed sandboxing feature can be useful for namespacing, but is necessarily less restrictive than pledge and unveil.

An externally imposed sandboxing feature isn't necessarily less restrictive than pledge and unveil at all, although I'm curious why you think that is the case.

To say nothing of the fact that pledge and unveil are wholly dependent on developer opt-in.

A good sandboxing solution should be robust and not require the cooperation of the programs that require sandboxing.

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#25

Post by tightbookkeeper »

ruthmarx wrote: post #21
yjftsjthsd-h wrote: post #18

Earlier quoted context omitted.

What does Sandboxing™ give you that pledge+unveil doesn't?

> Sandboxing™ Writing it like this is kind of funny, hoenstly, but not for the reasons you probably think. > give you that pledge+unveil doesn't? Not requiring the cooperation of developers to opt-in, for starters. You really think pledge and unveil are equivalent to sandboxing? Can you refer to any sandboxing solution or technologies that limit themselves to restricting syscalls and hiding file paths? Unveil is a lo…

> Not requiring the cooperation of developers to opt-in, for starters.

This is a good point. My initial thought is that the developers would know best what features their application needs? Furthermore, it's work that every user benefits from, rather than requiring an IT professional to reconfigure for each use case.

What do you see as the downsides?

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#26

Post by Panino »

> Executable file integrity enforcement

I assume but don't know for sure that this refers to Veriexec in NetBSD, and I'm not sure what in HardenedBSD. Anyone know?

https://man.netbsd.org/veriexec.8

My understanding is that Veriexec isn't enabled by default - the manpage says only that "[s]ome kernels already enable Veriexec by default." If you have this enabled, how do you upgrade binaries? The manpage says that in strict mode 1, write access to monitored binaries is allowed but then access is denied. So I assume that after file modification, root then runs veriexecgen and veriexecctl load as mentioned in the manual to update the signatures list. So it seems that strict level 1 isn't functionally different from a read-only /usr or even just root-owned binaries. In either case, you just need root to update targeted binaries. Surely I'm missing something and would appreciate some insight.

At a glance as an outsider, stricter modes appear somewhat functionally similar to "chflags schg" on BSD systems, where more work is needed to get around restrictions. In the case of schg, you have to reboot into single user mode, remove the schg flag, then modify the binary, and continue booting into multi-user mode. You could do this as a remote attacker (as in not having console access) depending on what boot files are or aren't protected with schg, but modifying all the necessary files can be a source of new problems.

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#27

Post by 0x457 »

ruthmarx wrote: post #24
ori_b wrote: post #23

Earlier quoted context omitted.

Most programs require a setup phase, where they want a great deal of access to the environment to set up the resources they use, and a steady state phase, where they need very little access beyond pre-opened file descriptors. An externally imposed sandboxing feature can be useful for namespacing, but is necessarily less restrictive than pledge and unveil. For example, in steady state on OpenBSD, most programs can't e…

> An externally imposed sandboxing feature can be useful for namespacing, but is necessarily less restrictive than pledge and unveil. An externally imposed sandboxing feature isn't necessarily less restrictive than pledge and unveil at all, although I'm curious why you think that is the case. To say nothing of the fact that pledge and unveil are wholly dependent on developer opt-in. A good sandboxing solution should…

Those are two different kinds of sandboxing. One protects application from itself - "here is what I use, if I try anything else, then it's a bug".

Sandboxing you're talking about protects system from the application. You really need both.

re: restrictiveness

With external sandboxing, you need to restrict to a common denominator of all application states you see youself observing that application. Internal sandbox can adjust itself as it goes.

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#29

Post by transpute »

saagarjha wrote: post #22
brynet wrote: post #16

It's easy to invent a chart that only you can get a nearly perfect score on. This does nothing to explain what any of these features are, what are "Boot hardening" and "sysctl hardening"? At least OpenBSD's innovations page makes an attempt to explain new concepts and features that have been developed over the years, and people can make any comparisons for themselves. https://www.openbsd.org/innovations.html

I mean, both of these are really just lists of mitigations. What would really be useful is why each of these has been developed, what attacks it tries to stop, why that was chosen as something worth protecting against, and what is out of scope for each of them.

Good LLM prompt seed :)

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#30

Post by h4ck_th3_pl4n3t »

Can somebody explain to me how anybody could verify or reproduce working address randomization and position independent executables?

This is basically what muslc does, but with the kernel itself offering a memset / malloc with randomized padding, right?

Also, what does ASLR brute force detection (SEGVGUARD) do? To me this sounds like malloc has a hook that maps process ids and tries to find heuristics of the allocated offsets?

Anybody know where those features are documented do someone can try to bypass/exploit it?

Post reply on HN