[HN Gopher] OpenBSD 7.5
___________________________________________________________________
OpenBSD 7.5
Author : SoftTalker
Score : 292 points
Date : 2024-04-05 02:19 UTC (20 hours ago)
(HTM) web link (www.openbsd.org)
(TXT) w3m dump (www.openbsd.org)
| brynet wrote:
| Announcement mail: https://marc.info/?l=openbsd-
| announce&m=171228270018970&w=2
| Panino wrote:
| I'm currently switching my Go code to Rust in part because of the
| syscall related Go trouble:
|
| > Users of syscall(2), such as Perl and the Go programming
| language were converted to use the libc functions.
|
| I think the following may still need to be converted:
| * unix.Pledge from golang.org/x/sys/unix * unix.Unveil from
| golang.org/x/sys/unix * terminal.ReadPassword from
| golang.org/x/crypto/ssh/terminal
| qweqwe14 wrote:
| Didn't Go already realize that it can't use direct syscalls on
| anything other than Linux? They made some mistakes in the past
| but by this point I think they learned their lesson.
|
| On Linux, using direct syscalls is a good idea, since it's
| _the_ stable userspace-kernel interface. There 's really no
| need for libc on Linux, each language should just implement
| it's standard library on top of syscalls.
| int_19h wrote:
| They knew it all along, since it's well-documented. But they
| don't seem to care about it until they get burned. Which
| first happened on macOS, so that was switched; then OpenBSD.
|
| This was previously discussed at length here:
| https://news.ycombinator.com/item?id=25999623
| pjmlp wrote:
| Like many other decisions, and as it happens with other
| technologies, reaching for it is a decision that outweights
| my preferences, given how it has managed to become
| unavoidable in many CNCF and DevOps products.
| akira2501 wrote:
| Ironically the libc itself fails to document how large of a
| stack you should have before you call into it. Which is why
| go, having goroutines, tried to avoid it in the first
| place.
|
| They didn't "get burned" they were "trying to provide a
| nice feature that wasn't as broadly compatible as they had
| hoped."
| LAC-Tech wrote:
| _There 's really no need for libc on Linux, each language
| should just implement it's standard library on top of
| syscalls._
|
| Rustix is a great implementation of that idea
| https://docs.rs/rustix/latest/rustix/
|
| Any similar projects in other langs?
| Cloudef wrote:
| Zig's standard library does not use libc
| qweqwe14 wrote:
| It would be great for Rust to have a Linux target that
| doesn't use libc, but from what I've read, not many people
| are interested in this.
|
| Found this as well: https://github.com/sunfishcode/mustang
|
| Some discussion here:
| https://github.com/bytecodealliance/rustix/issues/76
| zokier wrote:
| > There's really no need for libc on Linux, each language
| should just implement it's standard library on top of
| syscalls.
|
| Its not always not so clearcut. For example using pthreads
| instead of just calling clone can be useful for interop etc.
| Similarly, anything involving NSS is probably best done
| through libc. Having libc malloc integrated makes interacting
| with other C libs easier. And so on.
| tedunangst wrote:
| They were converted months ago.
| citizenpaul wrote:
| Forgive my ignorance but is this something limited to go on
| openbsd? Or is it a general isssue with go?
| ikmckenz wrote:
| Have you updated your packages with 'pkg_add -u'?
| Panino wrote:
| Yes, I run -current so I update packages frequently.
|
| After tedu's comment here I installed 7.5 in a VM and could
| build and run my Go software in it successfully, so I figured
| there were some Go build or config files or something
| somewhere getting in the way. I pkg_delete'd go, removed
| every Go build/config file I could find, and re-added Go with
| pkg_add. Now I can build apps with the previously mentioned
| modules; everything works fine now.
|
| Thank you for the responses. :-)
| a-french-anon wrote:
| Does anyone know if there's any plan to reintroduce xattrs in
| FFS2? Probably the only modern UNIX without it in its main FS(s).
|
| Or for a more standard/modern FS like XFS (I don't expect OpenBSD
| to go for ZFS bloat).
| ByQuyzzy wrote:
| They made their FFS 64-bit. That's what you get. And FFS is
| _THE_ standard.
|
| In short no. Also they removed softupdates, code was old and
| slow and was holding back the quest to unlock.
| znpy wrote:
| > And FFS is THE standard
|
| What's that supposed to mean? ed is the standard text editor,
| yet we don't actually expect anyone to use it (let alone know
| it...)
| ByQuyzzy wrote:
| It means no meme filesystems will be tolerated. There are
| tons of operating systems out there if you don't like ffs.
| jabl wrote:
| > They made their FFS 64-bit.
|
| What does this mean? 64-bit inode numbers? 64-bit timestamps?
| Something else?
|
| > Also they removed softupdates,
|
| Shame in a way, I remember reading McKusick's paper and being
| impressed. But I guess it's the antithesis of batching, which
| turned out to be more important for performance than avoiding
| the extra I/O due to journalling. Also the implementation was
| AFAIU fearsomely subtle and tricky.
| ByQuyzzy wrote:
| Read the manual page, I'm not going to type it all in here.
| volkadav wrote:
| https://unixgeeks.net/posts/2022/10/check-for-openbsd-ffs-
| fi... may be helpful. tl;dr - timestamps and blocknumbers
| are 64b in FFS2, intro'd in 4.2 and made the default (more
| or less) in 6.7
| yjftsjthsd-h wrote:
| > Or for a more standard/modern FS like XFS (I don't expect
| OpenBSD to go for ZFS bloat).
|
| At some point, I think I heard that they might use HAMMER2,
| which would be nice.
| alberth wrote:
| https://github.com/kusumi/openbsd_hammer2
|
| A developer was making active progress, but hasn't made any
| commits since Dec
| jmclnx wrote:
| >plan to reintroduce xattrs in FFS2?
|
| With unveil(2) and maybe pledge(2), I do not think there is a
| need for Extended Attributes. To me, all it does is add
| complexities not really needed in OpenBSD.
| zokier wrote:
| I don't see how unveil/pledge is in any way related to xattrs
| patrakov wrote:
| You confuse ACLs and xattrs. SAMBA uses Extended Attributes
| to store thinks like Hidden and System flags on files, so
| that Windows clients can manipulate them. NT ACLs, too.
| omnibrain wrote:
| No song this time.
| dbolgheroni wrote:
| Sometimes the song release comes after the software release.
| bheadmaster wrote:
| The removal of generic syscall(), and introduction of
| pinsyscalls() which registers the precise entry location of every
| system call used by a program, makes me think of some kernel-
| level ABI issues that Linux has.
|
| In particular, kernel ABI is the main stable interface that Linux
| exposes - and all applications can just use syscalls directly
| without having to interface with the libc at all. However, that
| means that kernel must not change its ABI lest it risks breaking
| compatibility, and each functionality that isn't implemented
| inside of the kernel (e.g. GUI stuff) cannot be implemented
| completely portably.
|
| However, using pinsyscalls(), a kernel can make sure that
| syscalls can only be called from the libc - therefore, making the
| libc de-facto ABI! Which allows for much more freedom in changing
| kernel ABI, as long as the libc follows through. Perhaps this way
| the system can go away from the syscall-level ABI and move over
| to the libc ABI / shared library ABI?
| newpavlov wrote:
| Honestly, I think that making libc THE system interface is a
| mistake. Ok, I understand issues with the Linux approach of
| exposing raw syscalls (though it works well enough in practice
| and ossification could be amended by some kind of syscall
| versioning scheme), but why in the world can't you introduce
| libsystem/libsyscall/libopenbsd which would contain only
| "syscall" functions? Why do you need all the C junk in a
| library for talking with OS?
| tedunangst wrote:
| Nothing stops you from making your own libsystem. Or still
| just making syscalls.
|
| Nobody seems to understand how this feature works, even
| though it's quite simple. The process asks the kernel to only
| allow system calls from one segment. If you don't like that,
| don't ask for it.
| newpavlov wrote:
| Lack of stable syscall ABI is what stops me. It can be only
| done by OS developers.
| nanolith wrote:
| A "stable" syscall ABI means that the interface between
| kernel and userland is ossified, potentially forever. If
| OpenBSD did this, then many of the security improvements
| it has made over the years, which has required the
| deletion of old (bad) system calls and the modification
| of other system calls to make them safer, never could
| happen without fundamentally breaking userland.
|
| Calling into system calls in libc is not a hindrance at
| all for the use of other languages, any more than calling
| directly into a syscall would be. Cross-language function
| calls have been a time honored tradition since the first
| compilers were developed.
|
| Linux's ossified syscall ABI is a quirk of Linux, and not
| a feature found in most, let alone many, operating
| systems.
| aforwardslash wrote:
| Bullshit. A stable syscall api reflects a well designed
| kernel interface. You can obviously extend on it and
| deprecate at your will. Thing is, call gates are quite
| more common now (they even have shortcut instructions in
| modern cpus) vs software interrupts (int80h), and there
| is quite some effort into of runtime linking vs static
| linking - yes, static linking can be used in libc-based
| ABIs but just defeats the purpose. In my opinion, libc
| should not be a broker for privileged operations. There
| are a plethora of reasons for this, but the most obvious
| is that languages may not use libc in their linkage.
|
| And FFS, Ive been using OpenBSD for well over 2 decades
| now. I'd say any syscall changes done in the OS are
| minimal compared to eg. linux.
| nanolith wrote:
| > Bullshit. A stable syscall api reflects a well designed
| kernel interface.
|
| Says who? I certainly wouldn't consider Linux's syscall
| ABI to be well designed. You know what is well designed?
| A stable facade that provides minimal overhead between
| two components, which prevents tight coupling. Like libc.
|
| > You can obviously extend on it and deprecate at your
| will.
|
| Only by breaking userland, which grinds this process to a
| crawl, even when it can happen at all. libc provides a
| better interface here.
|
| > Thing is, call gates are quite more common now
|
| I fail to see the relevance here. The mechanism by which
| syscalls are made doesn't make it cheaper to ossify your
| syscall ABI, nor does it improve security. It can
| certainly reduce the performance hit of a context switch.
| But, even with call gates, the overhead of a context
| switch is so high that adding the overhead of calling a
| wrapped function in libc is hardly going to matter.
|
| > and there is quite some effort into of runtime linking
| vs static linking
|
| What effort? Yeah, you have ld.so doing the relocation
| for you at runtime, but this happens once at program load
| time. Compared to everything else that must occur to load
| a program, dynamic linking adds minimal overhead.
|
| > In my opinion, libc should not be a broker for
| privileged operations.
|
| That's an interesting opinion, but beyond an unlisted
| "plethora of reasons", I don't see any relevant reason
| for this blanket ban. Having a single path into and out
| of the system call interface provides a way in which
| userland protections -- such as syscall pinning,
| immutable pages, etc., can be added. For defense in
| depth, this is useful.
|
| > but the most obvious is that languages may not use libc
| in their linkage.
|
| How does language runtime library linkage matter? What is
| the real difference to a language whether it calls read()
| or the read syscall? Either way, it has to marshal
| arguments through a FFI. Either way, it has to do the
| same amount of work. Languages must be ported to each
| operating system they run on. On OpenBSD and MacOS in
| particular, this porting means calling libc. On most
| OSes, libc is considered the preferred interface. On
| Linux, it's not, and because of that, folks assume that
| Linux's relative uniqueness here is somehow the default.
|
| There is really no point to directly using syscalls. In
| nearly every case for unistd, socket, and fcntl, the libc
| wrapper is negligible. You can do all of the same things.
| There are few, if any, enforced C-isms. Even where they
| exist, they can be abstracted with a middling to average
| FFI library. Performance-wise, the significant overhead
| is making the syscall. Calling a library to do this has
| little measurable effect.
|
| This is much ado about nothing.
| pjmlp wrote:
| UNIX is the C language runtime, so to speak, so naturally
| libc is THE system interface.
|
| It only became something else, when C got standardised, a
| tiny subset of it landed into ISO C, grew beyond UNIX, and
| the rest of the UNIX API surface landed at Open Group's
| POSIX.
|
| Obviously on the UNIX world nothing changed, until GNU/Linux
| came into scene and decided to act in another way, due to
| being GNU ecosystem + Linux kernel combo.
| newpavlov wrote:
| I do not dispute that it made sense during early days of
| UNIX. But today we write system software for these
| operating systems in many languages other than C. Maybe
| it's time to reconsider the dominant libc position instead
| of reinforcing it further?
|
| Linux has successfully paved the way and demonstrated its
| practicality. Yes, it made certain unfortunate mistakes
| along the way, but OpenBSD (or any other OS) can learn from
| those and provide a better solution.
| pjmlp wrote:
| Every other operating system does exactly the same in
| regardless to abstracting syscalls, regardless of being
| UNIX clone or not, GNU/Linux is the exception, not the
| rule.
|
| If you mean a C based OS ABI, there are many other
| alternatives, like on managed OSes, IBM and Unisys
| surviving mainframe and micro computers, OS IPC like
| COM/XPC/AIDL/FIDL/D-BUS.
| ByQuyzzy wrote:
| Do you know what Unix is or the C programming language? Your
| bafflement is entirely baffling. OpenBSD is never switching
| to Rust or Go or any of the new fad languages, so why not use
| libc? It's the Unix way after all.
| int_19h wrote:
| libc is already de jure ABI on the BDSs though, no? Since the
| OS doesn't really guarantee their stability or portability.
| dfc wrote:
| Does anyone know the story behind the artwork? Puffy does not
| look so good.
| gattilorenz wrote:
| Vaguely reminiscent of
| https://en.wikipedia.org/wiki/Creature_from_the_Black_Lagoon...
| riffraff wrote:
| I thought it was a nod to the statue of liberty at the end of
| Planet of the Apes (1968). I miss the days all OpenBSD
| releases came with a song!
| greyface- wrote:
| https://en.wikipedia.org/wiki/Ozymandias
| NortySpock wrote:
| If you prefer to hear it from a excellent narrator:
| https://youtu.be/xbLdz1kcQNw
| nullindividual wrote:
| Tex is an awesome narrator. Thanks for linking!
|
| "Comrade Stalin says there's bread on the Finnish line"
| dfc wrote:
| Do you know this to be the inspiration for the artwork or
| best guess?
| greyface- wrote:
| I inferred it based on the image's filename, alt text, and
| visual correspondence to the scene described in the poem.
| krylon wrote:
| Look upon my source tree, ye mighty, and despair!
| perihelions wrote:
| Nothing therein compiles.
| lenerdenator wrote:
| feels relevant looking over their list of discontinued
| architectures.
|
| each was made by teams sure they were going to be the next
| big thing in some market space...
| jaypatelani wrote:
| https://merveilles.town/@prahou/112217694585794119
| ch0ic3 wrote:
| For anybody wondering about the new pinsyscalls(2) suggest having
| a look at https://isopenbsdsecu.re/mitigations/pinsyscall/ . To
| be clear: I use OpenBSD on all my external-facing systems. I
| trust it infinitely more than any GNU/Linux distribution (esp
| with the recent xz.. "issue"), but I think it's important to do
| your own research and see what the contrarians say from time to
| time.
| calvinmorrison wrote:
| Do you think there's more value in combining 2 heterogenous
| systems (like openbsd up front, linux behind) than using one
| 'more secure' system throughout? I feel like the number of
| critical issues that have faced two systems at once is far
| fewer than a single system.
|
| Also I think it shows value in having independent
| implementations of standards. If you have 5x different xz tools
| or C compilers or Javascript engines, the threat is chopped in
| half, plus you can easily compare reference outputs between
| them (RE: on trusting trust)
| wannacboatmovie wrote:
| It's common practice for the ultra paranoid to use two
| firewalls, from different vendors, back to back, for this
| reason.
| terlisimo wrote:
| There is a name for this
| https://en.wikipedia.org/wiki/Swiss_cheese_model
| ch0ic3 wrote:
| For sure! An argument in OpenBSD circles is that contrary to
| popular belief one can have security through depth. This
| means that even though you'll never be 100% secure you can
| definitely make an attacker's job harder and their life more
| miserable. Of course, if the NSA wants to attack you then
| they'll probably succeed, but for your average script kiddy /
| botnet scanner / worm exploiting some vulnerability having
| multiple layers might be enough of a deterrent.
|
| I'm not a security person but I also think a lot of malware
| damage comes from companies / users using misconfigured or
| outdated software. As such, if you were a sysadmin, knew what
| you were doing and had the time, then running GNU/Linux is
| probably fine, but I'm not super knowledgeable. I just want
| to host a website or run a tor-relay on a VPS and not have to
| worry about updating my system as soon as some 0-day is
| announced in glibc or systemd; even if it's in the service
| itself, my hope is that by using a non-mainstream OS the
| exploit might not initially target it, hence giving
| sufficient time to see the news somewhere and patch / update.
| nanolith wrote:
| This site is often fairly balanced, but I think the author
| often jumps to conclusions. The pinsyscall feature is one place
| where many security researchers have jumped to conclusions,
| because they only see it from their narrow x86 oriented view.
|
| Yeah, on x86, I can craft a ROP attack that allows me to
| discover relocations for functions fairly trivially, especially
| for coarse ASLR, because I can read the text segment. But,
| ARM64 has execute-only support so that it's possible for code
| to execute, but not read, a text segment. In this situation,
| pinsyscall does add a valid defense in depth layer. It's still
| imperfect, but this does in fact raise the bar necessary to
| carry out a ROP attack when combined with randomized re-linking
| on boot ASLR. Further, once dynamic linking has occurred, the
| text segment for a binary is made immutable so that no mapping
| changes can occur, including mmap.
|
| I think that OpenBSD still has a long way to go before all of
| these defenses align, but they are far less trivial than the
| author makes them out to be, because none of them are meant to
| be used alone. OpenBSD developer decisions like these can
| sometimes appear to be casting about randomly, because they are
| making small improvements instead of building toward a
| particular goal. Sometimes, they hit gold as with W^X, which
| was widely adopted. Sometimes, their ideas stink, like
| systrace. But, I don't think it's wise to just dismiss these
| ideas out of hand.
|
| Instead, I recommend that people look to the history of
| OpenBSD, which has been more of an evolutionary approach to
| security instead of a revolutionary approach (i.e. Fuchsia).
| From an evolutionary perspective, pinsyscall makes sense as it
| is low-hanging fruit that can buy some security and can force
| applications to use a standard interface (libc) instead of
| making raw system calls. From a revolutionary perspective,
| pinsyscall just seems like a dead end. Revolutionary design has
| convergent effects -- all of the pieces come together in a
| perfectly engineered defensive shell. Evolutionary design has
| emergent effects -- fixes and features build on each other
| until they co-evolve into strong defenses.
| alberth wrote:
| Since you're clearly knowledgable ...
|
| What's your take on http://cheribsd.org (and CHERI as a
| concept overall)?
| nanolith wrote:
| I've been following CHERI for years. I'm a fan of runtime
| mitigations in hardware, better process isolation, and
| capability models. This couples nicely with an obsession of
| mine, which is the integration of formal methods into
| system and firmware development.
|
| That being said, CHERI has a long way to go before it makes
| it to any production system. ARM Morello has certainly
| breathed new life into it, as has its current push toward a
| RISC-V ISA. Going from R&D to synthesis on production
| hardware is a significant leap.
|
| It has inspired innovation in hardware much as seL4 and
| similar projects have inspired innovation in the formal
| methods field. For that, I'm grateful.
| pstuart wrote:
| Would the evolutionary approach be an advantage in allowing
| existing code bases to run with minimal modifications? So not
| perfect but safer than linux with minimal effort?
| nanolith wrote:
| I think that it's difficult to quantify whether X is safer
| than Y. Instead, we should look at what safety measures X
| or Y have in place, and whether these can be reasonably
| improved. Certainly, a single comment on a forum would do
| this topic a disservice.
|
| OpenBSD has clearly been in the business of making small
| improvements with each release. This model has worked for
| them, but it has also been part of what makes them
| controversial. I trust OpenBSD for my personal servers and
| my travel laptop. I use it as a build target for my
| projects.
|
| That being said, do I think that people should switch from
| Linux to OpenBSD? I wouldn't do this purely for security,
| because Linux has not been sitting still either. But, I
| think it's definitely a good idea to take lessons that
| OpenBSD has taught when configuring a Linux server: disable
| things you don't need, use the most aggressively secure
| options for services you provide, and add as much isolation
| between pieces that you can. Regardless of which OS you
| choose, you should spend time familiarizing yourself with
| what is required to harden the security for servers you
| make available with a public IP address.
|
| OpenBSD's "secure by default" idea is great until you need
| to enable a service, which widens its attack surface. Doing
| this safely requires research and knowledge. In this way, I
| don't think that OpenBSD is much different than the average
| Linux distribution. I openly admit that I like OpenBSD, but
| I don't want to steer people the wrong way by claiming that
| they would be safer using it. In fact, blindly switching
| operating systems could make folks less safe, because they
| will probably use the new operating system incorrectly.
| Instead, study and experiment.
| brynet wrote:
| > ARM64 has execute-only support so that it's possible for
| code to execute, but not read, a text segment.
|
| OpenBSD does xonly by default on multiple architectures
| (arm64, risc-v, ... g5 powerpc), including even amd64 on
| recent Intel/AMD CPUs supporting MPK/PKU:
|
| https://marc.info/?l=openbsd-cvs&m=167423045918820&w=2
|
| On machines that lack hardware-enforcement, at least on CPUs
| that can differentiate between traps for instruction-fetch
| and data-fetch, there is still benefit:
|
| https://marc.info/?l=openbsd-cvs&m=167517831914525&w=2
| (msyscall(2) part is now handled by pinsyscalls in -current)
| lenerdenator wrote:
| Would it be correct to say that OpenBSD is far more of a
| unified approach to kernel and userland development than
| GNU/Linux? As in, both ship as one unit, end-to-end, instead of
| interchangeable modules that make up GNU's ecosystem?
| alberth wrote:
| That's correct for all BSD's, not just OpenBSD.
|
| BSD = kernel + userland
| lenerdenator wrote:
| I might throw it on a VM soon.
|
| Maybe it'll finally scratch the ultimate nerdy OS itch.
|
| Probably not though.
| alberth wrote:
| Does pinsyscall mean Cosmo will no longer work on OpenBSD?
|
| https://github.com/jart/cosmopolitan
| The_Colonel wrote:
| > Copyright 1997-2024, Theo de Raadt.
|
| Caught my eye. I'm vaguely aware that Theo de Raadt is not the
| paragon of modesty, but would still expect a more "communal"
| copyright. Or is OpenBSD largely a one-man show?
| ninjin wrote:
| One would probably have to define "one-man show". But, no, Theo
| does not write most of OpenBSD's code. Although he certainly is
| the leader of the project. If the copyright statement bothers
| you, I can recommend the announcement e-mail (see "THANKS" in
| particular):
|
| https://marc.info/?l=openbsd-announce&m=171228270018970&w=2
|
| You will also find separate copyright statements in a lot of
| the source files and many carry the name of their authors.
| gtirloni wrote:
| Uh? Of course it's not a one-man show.
|
| https://github.com/search?q=repo%3Aopenbsd%2Fsrc%20copyright...
| jmclnx wrote:
| Are you referring to the text in the WEB Page ?
|
| https://www.openbsd.org/75.html
|
| I think that is because Theo de Raadt maintains the Site. As
| someone said the source files have their own copyright
| comments.
| phone8675309 wrote:
| I believe that copyright notice is for organizing the layout of
| the actual distribution images (ISO, etc) and for the music and
| artwork (though work-for-hire), not that Theo de Raadt is
| claiming copyright over all of the code in the distribution.
| ByQuyzzy wrote:
| The advantage of Theo being dictator is that big companies
| can't take over like they did with Linux.
| flykespice wrote:
| Linus is still dictator in the Linux kernel...
| infamouscow wrote:
| In what sense?
|
| The Linux kernel development model is one that embraces
| forking and submitting patching in a way that totally
| horrifies webdevs paid to mush together data transformation
| pipelines.
|
| Linus and Greg KH are both very clear that you don't have
| to use their "blessed" source trees. You're encouraged to
| fork.
|
| All of the genuinely moronic rhetorical arguments about
| "maintainer responsibility" are downstream from the GPLv2,
| which very clearly states in all capital letters there's no
| warranty implied or otherwise. The amount of time wasted on
| moot debates over that is mind boggling.
| ByQuyzzy wrote:
| Not since his vacation-style treatment.
| nequo wrote:
| I haven't heard about this. Can I read more about this
| somewhere?
| clort wrote:
| The problem with having a benvolent dictator is that the
| system is set up for a dictator to control things, and the
| chances of the next dictator being quite as benevolent are
| low.
|
| perhaps Theo has a plan for an eventual succession, perhaps
| not. Sometimes dictators can't really conceive of somebody
| else running the show so they don't plan for it.
| shrubble wrote:
| Is the artwork a reference to the poem, Ozymandias?
| rydgel wrote:
| it is
| another2another wrote:
| Always interesting to see the amount of work going into LibreSSL,
| but I'm not sure how much use it gets outside of OpenBSD which
| seems a bit of a shame.
| anonymous_union wrote:
| apple ships it
| lemper wrote:
| what i enjoy the most when openbsd has a new release is their new
| song. my favourite is the legend of puffy hood.
|
| https://www.openbsd.org/lyrics.html
| kstrauser wrote:
| "Pond-erosa Puff" lives in my head.
|
| I think we've been using this a while, huh?
| dyingkneepad wrote:
| Does anybody know what are the major companies employing OpenBSD
| developers these days? To what level are they invested?
| alberth wrote:
| I think this will be difficult to know, because IIRC, to commit
| to OpenBSD you must use an @openbsd.org account.
|
| So it's not like you can just look at the commit log and search
| for private company @names
|
| http://cdn.openbsd.org/pub/OpenBSD/Changelogs/
| whitepoplar wrote:
| Can anyone comment on the OpenBSD security model in 2024? Is it
| more secure than a minimal linux distro (or one configured to be
| so) such as Ubuntu Minimal or Debian Stable?
|
| I'm finding it quite difficult to compare OS "security" these
| days, whatever that means. Everyone seems to have their own
| crackpot opinions. If anyone with a security background could
| chime in, I'd be forever grateful.
| ranger_danger wrote:
| As far as I know, all of these statements are still true:
|
| https://web.archive.org/web/20220227172102/https://madaidans...
|
| https://isopenbsdsecu.re/
| yjftsjthsd-h wrote:
| > OpenBSD has no Mandatory Access Control (MAC) system like
| AppArmor or SELinux which prevents you from fully locking
| down user space.
|
| Isn't that pledge?
|
| And in general, I observe that lots of people are happy to
| say that OpenBSD's protections are no good, but somehow they
| can't be bothered to actually show a working exploit.
| MuffinFlavored wrote:
| > > OpenBSD has no Mandatory Access Control (MAC) system
| like AppArmor or SELinux which prevents you from fully
| locking down user space.
|
| Would this have mattered/stopped/mitigated the `xz` problem
| if systemd spawns opensshd and transiently loads infected
| .so shared objects?
| yjftsjthsd-h wrote:
| I'm not really super confident, but I think the problem
| is that sshd has to be able to spawn user sessions and
| those users are generally not supposed to be
| (meaningfully) confined by selinux or whatever. So I
| _suspect_ that it wouldn 't have helped, because a
| compromised sshd is necessarily in the prefect place to
| MitM or forge a session regardless of extra constraints.
| But take with a grain of salt.
| sillywalk wrote:
| AppArmor/SELinux require separate policy files to be
| written, to describe what an app can/can't do.
|
| Pledge/unveil are APIs that developers use to directly
| restrict what an app can do/can't do.
| zvmaz wrote:
| Is OpenBSD used in industry, in critical systems, etc.? If so,
| what are some examples of its use? Truly interested to know.
| mrweasel wrote:
| m:tier (https://www.mtier.org/refs/) claims to have customers
| in the oil and gas industry.
| tranxen wrote:
| There was this interesting talk [1] about how this ISP uses
| OpenBSD as BGP control plane.
|
| I used to heard that OpenBSD was often used as Internet facing
| middlebox (like firewalls/proxy/network load balancer) because
| of how good pf and relayd are.
|
| But it would surprise me if it would still be the case
| nowadays, OpenBSD seems to perform poorly [2] in terms of
| network throughput compared to the competition (VyOS/VPP). And
| I don't think this 7.5 upgrade helped a lot regarding this
| topic.
|
| [1]: https://gregsowell.com/?p=7069 [2]:
| https://ipng.ch/s/articles/2021/07/19/pcengines-apu6.html
| sjaak wrote:
| Just upgraded my small homeserver sysupgrade;
| sysmerge; pkg_add -u;
|
| Done! What a delight!
___________________________________________________________________
(page generated 2024-04-05 23:02 UTC)