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

31–40 of 81 posts

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#31

Post by transpute »

udev4096 wrote: post #28

For a hardened linux distro, take a look at kicksecure [0], which uses debian as base image [0] - https://www.kicksecure.com/

The list of disclaimers does impute confidence in their claims:

  most of the topics.. are still in development and are not yet used by default
  .. Kicksecure has adopted a best-effort, but admittedly quite weak approach
  CFI, SafeStack, automatic stack variable init..unlikely..due to.. resourcing
  kernel security issues.. are rooted deep within its design
  upstream developers are not very focused on serious security enhancements

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#32

Post by yjftsjthsd-h »

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.

True, meaningful in the general case, and completely irrelevant in this particular case, which started with specifically the question of OpenBSD applying the protection in question to its own base system. I actually agree that being able to externally impose a sandbox is super useful, but self-imposed restrictions are perfectly applicable in this usecase.

> 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.

I think that pledge and unveil are a type of sandboxing, certainly. And... I'm struggling to think of any sandboxing tech that does anything but limit syscalls and filesystem access. After rereading https://github.com/containers/bubblewrap?tab=readme-ov-file#... a bit, I suppose there's a case for being able to change what a sandboxed process can see rather than only masking (ex. PID 1 is a different process inside and outside the sandbox), but that strikes me as a slight variation rather than a fundamental difference in what is or isn't a "sandbox" per se. Likewise, I could see an argument that OpenBSD's approach is coarser than it could be; ex. I think you could restrict a Linux process to keep your real user and be able to read files but not write them even though they're owned by your user and are 644, but that's more of a convenience thing than a true fundamental difference - an OpenBSD process could open files in read mode, keep the socket open, and then pledge away open() altogether which gives you the same outcome with more legwork.

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#33

Post by yjftsjthsd-h »

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…

> 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.

With pledge, you can read config files, open a file handle to your logs, and then completely drop the ability to open() files at all for the remaining lifetime of the program. How would you do that from outside the program?

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#34

Post by shiomiru »

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…

> Can you refer to any sandboxing solution or technologies that limit themselves to restricting syscalls and hiding file paths?

FreeBSD has capsicum and Linux has seccomp-bpf & landlock. Of the three, pledge and unveil are the least horrible execution of the same idea (though capsicum is alright, too).

Obviously it's not a "run any random machine code on my system safely" type of sandbox, rather it's used by e.g. browsers as defense in depth so that attackers can't just outright call execl.

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#35

Post by yjftsjthsd-h »

Panino wrote: post #26

> 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 s…

I'm not familiar enough to know if this is particularly well adopted with NetBSD, but the obvious way to do it that I could see is A/B roots, where the active system can only update the inactive root.

I suspect the actual most likely case is that it's meant for appliances where the running system doesn't update itself, and updates are accomplished via actions like "go physically replace the SD card with the new one".

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#36

Post by ruthmarx »

0x457 wrote: post #27
ruthmarx wrote: post #24

Earlier quoted context omitted.

> 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…

> Those are two different kinds of sandboxing.

I'm arguing that only one example is sandboxing, the other is imposing limitations but doesn't meet the definition of sandboxing.

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#37

Post by ruthmarx »

yjftsjthsd-h wrote: post #33
ruthmarx wrote: post #24

Earlier quoted context omitted.

> 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…

> 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. With pledge, you can read config files, open a file handle to your logs, and then completely drop the ability to open() files at all for the remaining lifetime of the program. How would you do that from outside the program?

By monitoring and intercepting what the program is doing?

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#38

Post by yjftsjthsd-h »

tightbookkeeper wrote: post #25
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…

> 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?

I don't think it applies in this exact case (the base OS locking itself down), but in general:

> Furthermore, it's work that every user benefits from, rather than requiring an IT professional to reconfigure for each use case.

A distro could distribute, say, bubblewrap configs that automatically sandbox packages and every user could likewise benefit from that.

> What do you see as the downsides?

I think you're right that devs are best placed to lock down their own code, but if you don't have developer buy-in (or if they just don't want to make the effort or aren't available) then externally-imposed sandboxes are a lot easier for distro maintainers or end users to add after the fact than trying to patch the actual program source to do pledge+unveil or such.

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#39

Post by ruthmarx »

yjftsjthsd-h wrote: post #32
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…

> Not requiring the cooperation of developers to opt-in, for starters. True, meaningful in the general case, and completely irrelevant in this particular case, which started with specifically the question of OpenBSD applying the protection in question to its own base system. I actually agree that being able to externally impose a sandbox is super useful, but self-imposed restrictions are perfectly applicable in this…

> which started with specifically the question of OpenBSD applying the protection in question to its own base system.

Agreed, my answers did quickly go beyond the original point being claimed.

> I think that pledge and unveil are a type of sandboxing, certainly.

I think they are limitations and that's about it. They don't fit the metaphor of a sandbox IMO.

> but that strikes me as a slight variation rather than a fundamental difference in what is or isn't a "sandbox" per se.

Fundamentally I see a sandbox as something that is hard for the sandboxed application to escape, or even communicate out from except via limited well defined channels.

I don't think limiting syscalls alone satisfies that.

As a test, I think a robust sandbox should be able to apply to any program, no matter what it is doing.

Do you think pledge satisfies that? What about a complex piece of software that needs to use a number of syscalls that could be leveraged for an attack frequently, and so can't be meaningfully limited with pledge.

If that software has a vulnerability, the attacker now has access to the host system at least to the extent of the user the program was running under. That attacker certainly isn't sandboxed, they don't even have to escape a sandbox because there wasn't really one there, just 'concepts of a sandbox'.

Appreciating this discussion by the way!

Post reply on HN