[HN Gopher] Privilege drop, separation, and restricted-service o...
___________________________________________________________________
Privilege drop, separation, and restricted-service operating mode
in OpenBSD
Author : brynet
Score : 61 points
Date : 2023-02-19 15:10 UTC (7 hours ago)
(HTM) web link (sha256.net)
(TXT) w3m dump (sha256.net)
| Zurrrrr wrote:
| Security is more than just auditing code to remove bugs - it's
| also being prepared for worst case scenarios for bugs that
| inevitably exist but have not yet been found.
|
| For a security focused OS, OpenBSD is terrible in this regard.
| Pledge and Unveil are simply not sufficient.
|
| Something like SELinux, RSBAC, Even AppArmor is sorely needed.
| yazzku wrote:
| Aren't pledge/unveil precisely preparing for unknown bugs? Also
| they seem to be much easier to use than doing AppArmor chops.
| mrweasel wrote:
| Pledge and Unveil are better in one, maybe two respects.
|
| 1) The restrictions are put in place by the developer, who
| understand the correct and expected behaviour better than a
| random systems administrator.
|
| 2) Neither Pledge nor Unveil can be disabled by the user. Both
| SELinux and AppArmor (I don't know RSBAC) can be disabled, and
| is FREQUENTLY disabled because dealing with either systems are
| a major hassle to configure.
|
| I'm not quite sure how SELinux is better, it's perhaps more
| granular, but is that better?
| fpoling wrote:
| Linux approach delegates security to the system administrator.
| Hence Linux provides containers, SELinux etc. focusing on
| securing the existing binaries.
|
| OpenBSD assumes it is the programmer who is responsible for
| delivering secure code. Hence it provides the tools that
| require to modify the sources.
|
| One can argue for one or another approach, but both at the end
| deliver similar reduction of the attack surface.
| Zurrrrr wrote:
| I think that is a flawed way of looking at it. Stuff like
| SELinux assumes the system administrator or software can't be
| trusted, and provides ways to protect against future attacks
| while enforcing only the minimal access needed.
|
| It isn't letting programmers off the hook, and isn't an
| alternate approach.
|
| Unless you can be absolutely certain of the code you are
| running, which no one really can, then it's the better
| approach.
| traceroute66 wrote:
| > Something like SELinux, RSBAC, Even AppArmor
|
| The problem with AppArmor and friends is that they are hell on
| earth to configure and manage.
|
| And I'm saying that as a security conscious sysadmin !
|
| I don't mind spending little time to lock-down my systems a
| bit, but writing new AppArmor rules is about as attractive as
| bashing my head against the proverbial brick wall.
|
| Of course I leave AppArmor enabled to some degree, and I'm
| happy if a package comes with AppArmor rules ... but I ain't
| gonna be sacrificing days of my life writing, tweaking,
| troubleshooting my own rules.
|
| That's why I feel OpenBSD's answer is likely a good compromise.
| It adds a demonstrable level of security, and it doesn't stress
| out the sysadmin.
| binkHN wrote:
| > The problem with AppArmor and friends is that they are hell
| on earth to configure and manage.
|
| > I don't mind spending little time to lock-down my systems a
| bit, but writing new AppArmor rules is about as attractive as
| bashing my head against the proverbial brick wall.
|
| Yep. This is one of the prime motivators as to why OpenBSD
| did what they did. Often times, when AppArmor and similar
| solutions prevent a program from working properly, the first
| reaction is to disable it, and then these protections tend to
| stay disabled.
| daneel_w wrote:
| _> "For a security focused OS, OpenBSD is terrible in this
| regard. Pledge and Unveil are simply not sufficient."_
|
| Does that mean that OpenBSD's mitigations are trivial to
| exploit? "Terrible" and "simply not sufficient" are strong
| words. If so, can you provide a working proof-of-concept? I
| keep asking this of people who make this statement because I'm
| genuinely interested in seeing it demonstrated as it has
| negative implications for me, but no one wants to spend time
| proving their point.
| beachhead wrote:
| It'll never happen. Every single time this comes up it turns
| into the same thing over and over again. You must remember
| the person that said they'd "write a blogpost bypassing
| OpenBSD mitigations next week" and that's been well over a
| month now and, surprise, there's no blog about this.
|
| Everything OpenBSD does is wrong and trivial to bypass but
| everyone's too busy to do it. Maybe the dumbest part about
| this is that nobody on the other side of this is making
| claims that these mitigations are perfect in any way.
|
| Qualys has bypassed some OpenBSD malloc hardening features
| recently but then they don't go around making wild or
| insulting claims about how wrong and trivial they are either.
| Go figure.
| g0xA52A2A wrote:
| Just replying to provide some context [1] for those who
| come across this comment as I think it's pretty
| interesting. Also OpenBSD are working on something for this
| [2].
|
| [1] https://seclists.org/oss-sec/2023/q1/92
|
| [2] https://marc.info/?l=openbsd-tech&m=167673316325935&w=2
| sillywalk wrote:
| I believe that for the OpenBSD developers,
| SELinux/apparmor/seccmp are against their philosophy. [0]
|
| While they are very powerful tools, they require complex rules
| maintained outside the actual code, and their complexity may
| lead you to disable the Security stuff entirely, rather than
| try to re-write the rules your distro/package came with.
|
| OpenBSD had systrace back in the day to restrict system calls,
| but it suffered from the Time of Check/Time of Use/ problem,
| and was only used on one (sshd) program in the base system.
|
| [0] https://www.openbsd.org/papers/hackfest2015-pledge/
| rustifico wrote:
| Yet they are still writing everything in C.
|
| A well-polished turd is still a turd.
| crest wrote:
| Where is your shiny rust kernel and userland useable as
| desktop/laptop or server? Don't pull others down just because
| you have yet to deliver.
| chungy wrote:
| Now name the OS that isn't written in C.
|
| Hint: It's not Windows. It's not Linux. It's not Mac OS. It's
| not FreeBSD. It's not illumos...
| josephcsible wrote:
| Redox?
| medo-bear wrote:
| is it your daily driver
| hulitu wrote:
| MULTICS ?
|
| Apollo Domain OS ?
| mvdwoord wrote:
| Sour much?
| g0xA52A2A wrote:
| Changed "privilege separation" -> "separation" to fit within
| character limits.
| brynet wrote:
| Indeed. :-)
| g0xA52A2A wrote:
| LOL I thought it was my submission, totally missed the
| redirect.
___________________________________________________________________
(page generated 2023-02-19 23:01 UTC)