OpenBSD Journal

W^X now mandatory in OpenBSD

Contributed by tj on from the x-chromosome dept.

Traditional Unix has allowed memory to be mapped W | X. Everyone now knows thats a bad practice from a security standpoint, but the software ecosystem hasn't made much progress in this area. Theo de Raadt has just committed a change to begin blocking W^X violations in OpenBSD.

CVSROOT:	/cvs
Module name:	src
Changes by:	deraadt@cvs.openbsd.org	2016/05/27 13:45:04

Modified files:
	lib/libc/sys   : mmap.2 mount.2 mprotect.2 
	sbin/mount     : mntopts.h mount.8 mount.c 
	sbin/mount_ffs : mount_ffs.c 
	sbin/mount_nfs : mount_nfs.c 
	sys/kern       : kern_sysctl.c vfs_syscalls.c 
	sys/sys        : mount.h sysctl.h 
	sys/uvm        : uvm_mmap.c 
	usr.sbin/pstat : pstat.c 

Log message:
W^X violations are no longer permitted by default.  A kernel log message
is generated, and mprotect/mmap return ENOTSUP.  If the sysctl(8) flag
kern.wxabort is set then a SIGABRT occurs instead, for gdb use or coredump
creation.

W^X violating programs can be permitted on a ffs/nfs filesystem-basis,
using the "wxallowed" mount option.  One day far in the future
upstream software developers will understand that W^X violations are a
tremendously risky practice and that style of programming will be
banished outright.  Until then, we recommend most users need to use the
wxallowed option on their /usr/local filesystem.  At least your other
filesystems don't permit such programs.

This is a first step towards mandatory W^X, a plateau no one else has been able to reach yet. Some ports have been modified to adhere to this rule, but a number of others (JDK, GCC, Mono, Chromium, etc) will need the /etc/fstab workaround until they can be fixed upstream. Firefox is a notable exception, having been refactored in just the last year. While these remaining violators are being reworked, an initial method has been introduced to differentiate between filesystems whose binaries are or are not entirely W^X-safe.

None of the base system binaries violate this check, so there should be no noticable effect if you don't have any third party packages installed.

More information for -current users can be found in the usual place.

(Comments are closed)


  1. By PaX Team (94.21.46.17) pageexec@freemail.hu on pax.grsecurity.net

    PaX has had MPROTECT since 2000 which is a strict superset of what OpenBSD not-reinvented-here as W^X a few years later and what Theo had called a POSIX violation (which it never was). nice to see you guys come around, better late than never ;). FWIW Apple's iOS also made this move a few years ago already and even vanilla Linux does the same with SELinux (yes, ouch but the capability is there and enforced in real life policies).

    as for fixing/adapting userland, noone does it right, not even Firefox (it 'works' with OpenBSD only because its W^X doesn't actually enforce true exclusion of the W/X rights unlike MPROTECT in PaX has always done). grsecurity has had GRKERNSEC_RWXMAP_LOG for many years now to help users identify such use.

    as for proper runtime code generation, it will require more surgery than simply changing mmap/mprotect flags, using dual maps and/or temporary files, etc. namely, what must be ensured is that the address space that generates the code is different from the one consuming (executing) it (not unlike how ahead-of-time compilation is done and why it's considered 'trusted'). i know of only one academic example of such an approach, SDCG for the V8 JIT engine (available on github after i had requested it back then) which is not a spring chicken either.

    1. By Anonymous Coward (82.123.26.226) on

      > PaX has had MPROTECT since 2000 [...] grsecurity has had GRKERNSEC_RWXMAP_LOG for many years now [...] etc.

      And, out of curiosity, how many people use PaX or GRsecurity on Linux?

      NetBSD is slowly moving toward PaX, and switching on all the knobs one by one as far as I can tell. Good for them.

      And yet, I have never seen a well-known Linux distribution use either PaX and GRsecurity in its standard installation, or even offering that option, and I have quite a few years of experience.

      Debian, Red Hat, CentOS, SUSE, OpenSUSE, Gentoo, to name a few: none of them, as far as I know, offer either PaX or GRsecurity as an installation option, and certainly not by default.

      Please don't mention SELinux, it's dead on arrival, no one uses it, even though it is being offered in all major Linux distributions. See here for details:

      https://utcc.utoronto.ca/~cks/space/blog/linux/SELinuxBeyondSaving

      So, W^X may not be (please note I said ''may'', OpenBSD aficionados!) as good as PaX, but what good is having superior technology if it is unused? At least, OpenBSD uses W^X by default. And a shitload of other stuff, uncluding pledge, to improve security BY DEFAULT. In the standard installation. No additional knobs, fiddling or configuration option necessary.

      Again, this is an honest question: who uses PaX by default? Who uses GRSecurity by default? Why are these better than WX? I'd like some serious technical response from the PaX team.

      1. By Anonymous Coward (202.137.243.17) on

        > > PaX has had MPROTECT since 2000 [...] grsecurity has had GRKERNSEC_RWXMAP_LOG for many years now [...] etc.
        >
        > And, out of curiosity, how many people use PaX or GRsecurity on Linux?

        Probably more than use OpenBSD.

        Let's see how many distributions use OpenBSD...

        There's OpenBSD, obviously, and
        err

        Oh.

        1. By kraileth (77.6.101.136) on eerielinux.wordpress.com

          > > And, out of curiosity, how many people use PaX or GRsecurity on Linux?
          >
          > Probably more than use OpenBSD.

          That one's not even worth a real reply. Try harder next time.

          > Let's see how many distributions use OpenBSD...
          >
          > There's OpenBSD, obviously, and
          > err
          >
          > Oh.

          Just in case you really have no clue at all: The *BSD family consists of complete operating systems whereas Linux is just a kernel that is bundled with (most of the time) the GNU userland to be of any real use. For that simple reason there just is no need at all for "BSD distributions". If you are really looking for something that's close to your distributions, look at forks like Bitrig (yes, such things do exist!). If not, have a look at how much OpenBSD technology is used throughout the net. Good luck finding any Linux distro that does not provide OpenSSH (to name just one of a whole lot of things that come from OpenBSD)!

          You don't have to be grateful for it - it's permissively licensed and you're quite free to do with it whatever you wish. ;) Still it's a question of character to at least show some respect when it comes to a small project that spawned so many important things (some of which we all more or less depend on today).

        2. By Anonymous Coward (160.83.30.147) on

          > > > PaX has had MPROTECT since 2000 [...] grsecurity has had GRKERNSEC_RWXMAP_LOG for many years now [...] etc.
          > >
          > > And, out of curiosity, how many people use PaX or GRsecurity on Linux?
          >
          > Probably more than use OpenBSD.
          >
          > Let's see how many distributions use OpenBSD...
          >
          > There's OpenBSD, obviously, and
          > err
          >
          > Oh.

          nice trolling attempt, try harder.

          how about - everyone uses pax - pax is used in many unix derivates as a synonym to cpio. :P

          FYI: Pax is used in trusted Debian, is a compiletime option in gentoo/hardened, was included in flavours of rocklinux/t2-project Linux (all compiletime, since your supposed to compile them), is Default in alpine Linux. I don`t know for sure wether openwall has it active.
          you could at least do your homework.

      2. By PaX Team (94.21.46.17) pageexec@freemail.hu on pax.grsecurity.net

        > Debian, Red Hat, CentOS, SUSE, OpenSUSE, Gentoo, to name a few: none of them, as far as I know,
        > offer either PaX or GRsecurity as an installation option, and certainly not by default.

        Hardened Gentoo? Arch? even Debian and OpenSUSE have grsec kernel packages (though their userland support is lacking wrt to the other distros). as for other users, there're many commercial devices and service providers that run a grsecurity kernel.

        > Again, this is an honest question: who uses PaX by default? Who uses GRSecurity by default? Why are these better than WX?

        i already linked in the doc i wrote on MPROTECT, do you have any specific question that is not answered there?

        1. By kraileth (77.6.101.136) on eerielinux.wordpress.com

          > > Debian, Red Hat, CentOS, SUSE, OpenSUSE, Gentoo, to name a few: none of them, as far as I know,
          > > offer either PaX or GRsecurity as an installation option, and certainly not by default.
          >
          > Hardened Gentoo? Arch? even Debian and OpenSUSE have grsec kernel packages (though their userland support is lacking wrt to the other distros). as for other users, there're many commercial devices and service providers that run a grsecurity kernel.

          Arch Linux user here who deals with both Gentoo and Debian at work. Sorry, you somehow missed the point. First things first: The Hardened Gentoo project is great. But to use any hardened options, you need to change the profile on your system and then recompile toolchain, kernel, etc. That's certainly not the default.

          With Arch, there's packages like linux-grsec available, yes. It's been quite a while since I read through the installation guide for Arch, but when I did, no hardened options where mentioned there. I've also yet to come across any fellow Arch user who uses such a kernel. Sorry, not a default, either.

          More or less the same thing on Debian. No installer option, not advertized at any prominent place. Haven't touched OpenSUSE in years but I'd be surprised if it was much different there.

          So let's sum things up: Tight security features are available on Linux. If - and ONLY IF - you already know what you want and where to search for it. I assume that it wouldn't be too hard to settle on the fact that thus it's OPTIONAL?

          But, hey, even though I'm clearly on OpenBSD's side, I'll help you out a bit: There's this nice little Linux distro called Alpine Linux. They do it the other way round: You CAN install a vanilla kernel if you really wish but by default it's grsec enabled. Alpine does a lot of things right actually and thus proves that it's in fact possible. If I had to set up a non-BSD router or anything Alpine would clearly be my first choice. Too bad that this little gem is not that well known in the Linux community.

          1. By PaX Team (94.21.46.17) pageexec@freemail.hu on pax.grsecurity.net

            > > > Debian, Red Hat, CentOS, SUSE, OpenSUSE, Gentoo, to name a few: none of them, as far as I know,
            > > > offer either PaX or GRsecurity as an installation option, and certainly not by default.
            > >
            > > Hardened Gentoo? Arch? even Debian and OpenSUSE have grsec kernel packages (though their userland support
            > > is lacking wrt to the other distros). as for other users, there're many commercial devices and service providers
            > > that run a grsecurity kernel.

            > Sorry, you somehow missed the point.

            the questioner said that none of the above distros offered grsec even as an option which is factually false as i showed it. as for what's available as default, you're also wrong, see below.

            > First things first: The Hardened Gentoo project is great. But to use any hardened options,
            > you need to change the profile on your system and then recompile toolchain, kernel, etc.
            > That's certainly not the default.

            this is true only if you do it the hard way and convert an existing non-hardened gentoo installation to a hardened one. the preferred way is to start from a stage3 or stage4 hardened installer, e.g., http://distfiles.gentoo.org/releases/amd64/autobuilds/current-stage3-amd64-hardened/. that's as default as it can get and most definitely not optional.

            > They do it the other way round: You CAN install a vanilla kernel if you really wish but by default it's grsec enabled.

            unfortunately last i checked they settled on a rather old kernel (4.1?) and thus have been missing out on certain advancements since, such as the new size overflow plugin we released last autumn or RAP we released over a month ago with 4.5.

            1. By kraileth (77.6.101.136) on eerielinux.wordpress.com

              > the questioner said that none of the above distros offered grsec even as an option which is factually false as i showed it. as for what's available as default, you're also wrong, see below.

              As I understand it, he complained that there's no option in the installer that will install a hardened system. Just think the option to use LVM or encrypt the home directory in the installer. In fact I never saw anything like that. He surely didn't mean to say that you don't have the option to use it as that is pretty obviously wrong.

              > this is true only if you do it the hard way and convert an existing non-hardened gentoo installation to a hardened one. the preferred way is to start from a stage3 or stage4 hardened installer, e.g., http://distfiles.gentoo.org/releases/amd64/autobuilds/current-stage3-amd64-hardened/. that's as default as it can get and most definitely not optional.

              Yes sir, that's the default for a non-default installation method, I'll give you that! Just to see if I wrong you here, I took a look at the Gentoo manuals again. Haven't done so in quite some time and was surprised that they have redone them in quite a nice way. Still: The word "hardened" appears two or three times in the whole installation section of the handbook. And it's either in a directory listing or in the output listing of profiles. They are NOT mentioned in the installation instructions. So I don't see the necessity to withdraw my statement: You can have good security on Linux. You just need to know first what you want and where to search for it.

              > unfortunately last i checked they settled on a rather old kernel (4.1?) and thus have been missing out on certain advancements since, such as the new size overflow plugin we released last autumn or RAP we released over a month ago with 4.5.

              As far as I know, Natanael Copa has been hired by Docker. He's been keeping the kernel quite current for Alpine for quite some time. Probably he has less time for it these days.

              1. By PaX Team (94.21.46.17) pageexec@freemail.hu on pax.grsecurity.net

                > > the questioner said that none of the above distros offered grsec even as an option which is factually false as i showed it. as for what's available as default, you're also wrong, see below.
                >
                > As I understand it, he complained that there's no option in the installer that will install a hardened system.

                gentoo doesn't have an installer, it's a manual process.

                > > this is true only if you do it the hard way and convert an existing non-hardened gentoo installation
                > > to a hardened one. the preferred way is to start from a stage3 or stage4 hardened installer, e.g.,
                > > http://distfiles.gentoo.org/releases/amd64/autobuilds/current-stage3-amd64-hardened/. that's as
                > > default as it can get and most definitely not optional.
                >
                > Yes sir, that's the default for a non-default installation method, I'll give you that!

                you're wrong again. let me quote https://wiki.gentoo.org/wiki/Handbook:Main_Page: "A stage3 installation is the only supported installation as of now.". this holds for Hardened Gentoo as well of course whose stages can all be found at https://www.gentoo.org/downloads/.

                1. By kraileth (77.6.104.238) on eerielinux.wordpress.com

                  > > As I understand it, he complained that there's no option in the installer that will install a hardened system.
                  >
                  > gentoo doesn't have an installer, it's a manual process.

                  You're quite good at misunderstanding people. So good actually that I wonder if it's probably intentional? No, Gentoo does not have an installer - nor does Arch since they abandoned the AIF. Hairsplitting aside, this does not change the fact that the person who wrote the original comment observed that there's no installer option for grsec in any of the better-known distros.

                  > you're wrong again. let me quote https://wiki.gentoo.org/wiki/Handbook:Main_Page: "A stage3 installation is the only supported installation as of now.". this holds for Hardened Gentoo as well of course whose stages can all be found at https://www.gentoo.org/downloads/.

                  No, sorry. You missed the point again. Using a stage3 tarball has in fact been the only supported method with Gentoo for a long time now! So what? You can install hardened Gentoo if you know about it. You can install Gentoo with μclibc or with musl (even though I had a lot of problems when I attempted the latter quite a while ago). Nobody claimed the opposite.

                  Just to make it completely clear: The installation process that is described in a lot of detail in the official handbook DOES NOT advise you to use a hardened installation. It does not even actively point you in that direction. And since the official installation process does not provide a system with a hardened profile, grsec has to be considered optional, non-standard on Gentoo, too. That - and only that - was the original point: Tight security is optional on Linux (and most other operating systems).

                  1. By PaX Team (94.21.46.17) pageexec@freemail.hu on pax.grsecurity.net

                    > > > As I understand it, he complained that there's no option in the installer that will install a hardened system.
                    > >
                    > > gentoo doesn't have an installer, it's a manual process.
                    >
                    > You're quite good at misunderstanding people.

                    now you said two contradicting things about Gentoo:

                    > there's no option in the installer

                    and

                    > No, Gentoo does not have an installer

                    as for the original AC, they made two statements. one was that said distros didn't offer grsec as an option at all, and another (somewhat illogical but let's go with the apparent flow here) stating that such (non-existent) offer wasn't default. i reacted to the first statement with the list of distros where grsec is clearly offered as an option (with varying levels of support from the distro), and for the second statement i offered Hardened Gentoo (and not just Gentoo in general).

                    anyway, since you now went into ad hominem territory, i'm out and you can have the last word ;).

                    1. By Anonymous Coward (50.207.161.2) on

                      Clearly you forgot your own quote PaX while you were being so precise:

                      > the preferred way is to start from a stage3 or stage4 hardened installer,


      3. By Anonymous Coward (88.193.242.179) on

        If you look at anything as a hammer, you will use it as a hammer.

        SELinux is a system where access rights to data are determined by metadata that is part of the data, and transports transparently with the said data - between databases, file systems, and different locations of file systems. It's more of an extensible ACL client/server framework than anything else.

        When grsecurity security contexts can be used in databases, transported via network protocols, and the security server can be plugged by 3rd parties of information, please get back to me. Before that there will be many environments where it just doesn't fulfill the minimum requirements.

        SELinux never intended to compete with PAX, or other similar solutions. Of course it looks "shitty", just like trying to make a cake with a hammer would seem like a shitty idea. They were meant to solve different problems, and they both do it quite well actually. SELinux is used a lot in larger, and more complex environments, and it solves a few issues quite effectively.

        W^X and PAX are entirely different animals from SELinux. They could actually complement each other pretty successfully.

    2. By Anonymous Coward (185.100.87.73) on

      > as for fixing/adapting userland, noone does it right, not even Firefox (it 'works' with OpenBSD only because its W^X doesn't actually enforce true exclusion of the W/X rights unlike MPROTECT in PaX has always done).

      Could you elaborate on this?

      1. By PaX Team (94.21.46.17) pageexec@freemail.hu on pax.grsecurity.net

        > Could you elaborate on this?

        you quoted a bit too much for me to decipher which part you meant, can you be more specific?

        1. By Just Another OpenBSD User (77.85.130.233) on

          > you quoted a bit too much for me to decipher which part you meant, can you be more specific?

          This is exactly what you get from the lunatic tech support of the security kernel plugin no distribution includes.

        2. By Anonymous Coward (81.7.15.115) on

          > you quoted a bit too much for me to decipher which part you meant, can you be more specific?
          >

          Sorry. I wanted to know what you meant when you said that W^X doesn't enforce true exclusion.

          1. By PaX Team (94.21.46.17) pageexec@freemail.hu on pax.grsecurity.net

            > Sorry. I wanted to know what you meant when you said that W^X doesn't enforce true exclusion.

            MPROTECT in PaX was designed to control runtime code generation which means not only controlling the ability to create rwx maps but also *any* kind of transition that can effectively result in the same. this latter step is what's been missing in OpenBSD's W^X. as a result OpenBSD is unable to prevent runtime codegen and thus exploit writers can still end up with executing shellcode. this is not possible under PaX (or more precisely, grsecurity as i don't deal with the file system access part), and with RAP their options for code reuse attacks are pretty much eliminated now as well.

    3. By Anonymous Coward (82.68.199.130) on

      > PaX has had MPROTECT since 2000 which is a strict superset of what OpenBSD not-reinvented-here as W^X a few years later and what Theo had called a POSIX violation (which it never was). nice to see you guys come around, better late than never ;). FWIW Apple's iOS also made this move a few years ago already and even vanilla Linux does the same with SELinux (yes, ouch but the capability is there and enforced in real life policies).

      yep.

      > as for fixing/adapting userland, noone does it right, not even Firefox (it 'works' with OpenBSD only because its W^X doesn't actually enforce true exclusion of the W/X rights unlike MPROTECT in PaX has always done). grsecurity has had GRKERNSEC_RWXMAP_LOG for many years now to help users identify such use.

      There's a big problem with userland. The very few pieces of software which manage to handle enforcing W^X at all are treating it as something they have to work around in special cases, rather than treating it as "what they should be doing in the normal case". Even without a kernel that is enforcing (or at least noisily logging) PROT_WRITE|PROT_EXEC maps, it's still safer for them to avoid these mappings, but they do it anyway. We see libffi going through some pretty nasty steps parsing /proc to try and figure out if it's running on a Linux kernel that enforces W^X and reluctantly avoids PROT_WRITE|PROT_EXEC mappings in those cases, but tries to get away with W|X wherever possible - this just doesn't make sense to me.

      > as for proper runtime code generation, it will require more surgery than simply changing mmap/mprotect flags, using dual maps and/or temporary files, etc.

      These methods aren't perfect, but they raise the bar, and mean that the userland code has to be split up to some extent - people have to think about it more. It's not the end goal but I think it's a useful stepping stone. With webkit, v8, pcre's jit (though we have disabled this in ports), java and a handful of other languages relying on W|X mappings, we're still some way off being able to enforce W^X on the filesystem used for package installs (hopefully we will get per-binary annotations soon so we can tighten the ratchet), further enforcement by default at this point seems premature - we're currently at a stage of preventing mapping that we are certain should not be permitted, and (importantly) classifying user software behaviour at runtime by being a bit awkward but trying not to get too far in the way such that users have no alternative but to disable the mechanism. This isn't done as a patchset or something that users can turn off at will, so at this point it's still important that it doesn't prevent people from getting work done..

    4. By journeysquid (Tor) on http://www.openbsd.org/donations.html

      > its W^X doesn't actually enforce true exclusion of the W/X rights unlike MPROTECT in PaX has always done

      Could you explain?

    5. By Sebastian Rother (79.247.132.99) on

      > PaX has had MPROTECT since 2000 which is a strict superset of what OpenBSD not-reinvented-here as W^X a few years later and what Theo had called a POSIX violation (which it never was). nice to see you guys come around, better late than never ;). FWIW Apple's iOS also made this move a few years ago already and even vanilla Linux does the same with SELinux (yes, ouch but the capability is there and enforced in real life policies).
      >
      > as for fixing/adapting userland, noone does it right, not even Firefox (it 'works' with OpenBSD only because its W^X doesn't actually enforce true exclusion of the W/X rights unlike MPROTECT in PaX has always done). grsecurity has had GRKERNSEC_RWXMAP_LOG for many years now to help users identify such use.
      >
      > as for proper runtime code generation, it will require more surgery than simply changing mmap/mprotect flags, using dual maps and/or temporary files, etc. namely, what must be ensured is that the address space that generates the code is different from the one consuming (executing) it (not unlike how ahead-of-time compilation is done and why it's considered 'trusted'). i know of only one academic example of such an approach, SDCG for the V8 JIT engine (available on github after i had requested it back then) which is not a spring chicken either.

      I offer you one Solution: Commit PATCHES to the Project. There are clever people at the OpenBSD-Project and (in case you speak for anyone at "your team" your side maybe too).

      Solution is simple: SEND DIFFS for review. You can do it better by keeping things and APIs simple? Great...

      Theo proofed to be a real hacker, he analysed Bugs in the CORE-Architecture of the INTEL CPUs.

      Reference: http://marc.info/?l=openbsd-misc&m=118296441702631

      I am not a Fanboy.. but even I found a Bug in the OpenBSD PF...

      Don't get me wrong but: Posting in this Blog WONT change anything! You can start by assisting to bring back functions to this Blog (user registration, forgot my password function) and improve the CGI Code if you like... Then you would do something many users (including me) would like!

      If you can't do even this: Well.. words wont Change something...

      I say it clear: YOU ARE RIGHT.. now go on... move forward.... or try to change what you dislike by sending in Patches for what you think you can do better...


      Kind regards,
      Sebastian Rother

      1. By Anonymous Coward (188.29.29.228) on

        They don't want to help, they want credit.

        1. By grey (71.80.236.218) on

          > They don't want to help, they want credit.

          No one has ever tried to discredit them.

          That said, sixteen years after PaX was pioneered, and we still have PaX Team ranting on about W^X on a site devoted to OpenBSD, which created W^X some years later.

          Pax, is even featured as the primary theme of the film Serenity based on the Firefly TV show. Don't think it's related? Oh well, maybe it isn't; certainly what was said about Pax in a film of mass appeal was not positive but condemning.

          Perhaps PaX Team would care to look over the tales of Edwin Armstrong (inventor of FM radio), or how much credit Philo Taylor Farnsworth (inventor of the Cathode Ray Tube, and co-inventor of the fusor, the first human made device that created fusion) received for their pioneering work.

          Are they cited in the literature? Of course! Just like PaX. Did everyone end up using their inventions? Not quite as they were originally developed, no. Similarly, we may still have mass produced cars, but they are no longer the Ford Model T.

          Did those other inventors get folded into the mainstream & remunerated? Doubtlessly not as well as they would have wished. For that matter, OpenBSD does not get a lot in the ways of remuneration if I am to believe the donors list contributions, but at least they use licensing which is compatible with extant large business interests and their code is derived from with far more frequency (e.g. Services For Unix in Windows, or OpenSSH in OS X). OpenBSD, like any BSD derived codebase, receives credit as stipulated in the license, just as they have maintained credit for their provenance. Credit, is not the same as earning money or remuneration, it is synonymous with acknowledgement and attestation.

          BSD did not begin as OpenBSD after all, Unix began at Bell Labs, but Ken Thompson took a sabbatical at UC Berkeley in 1975 and thus BSD was born, derived from such things. We are long past the AT&T vs BSDi lawsuit, many of these facts are so old as to be boring, certainly I don't expect Ken Thompson to come onto this website and toot his own horn every time some feature he helped pioneer is mentioned. PaX Team seems to have other issues at play which are not meaningfully elucidated in their contributions to the dialog on this site.

          Since credit, is not the same as remuneration, you don't see BSD developers, of any branch, harping on features pioneered on a BSD but utilized elsewhere, even when they may be reinvented, because to do so, to me, speaks to some sort of erroneous belief that a horn must be tooted constantly when the sheet music has already been scored and the tune is well known to those who pay attention already.

          I don't know what PaX wants with regards to the OpenBSD project, and they are not doing a very good job of clarifying that based on what I have read for them now for over a decade at this point. If PaX Team has an axe to grind, I would suggest they focus their attention efforts and energy on instead collaborating with projects such as SubGraphOS https://subgraph.com/ which are following in the lead of defunct distributions such as Admantix in integrating PaX into the base system. PaX is GPLed and as such, not the first choice for BSDs of any variety, and most certainly not the first choice for major vendors in the commercial computing space either. It is wonderful for open research, but there is a lot more to existence than that, there always has been, and there always will be.

          Their presence here, does not seem constructive to the dialog or goals of OpenBSD, and I would again suggest that if they want to see wider adoption of PaX, they focus on projects which already have integrating PaX into their base system as an objective. It is not an objective of the OpenBSD project, and after a decade of reading this kind of stuff, it doesn't seem like it merits arguing about.

          Maybe I am missing something, and PaX Team thinks that a civil lawsuit would be merited? That did not go so well for AT&T when they sued BSDi, and BSDi lives on as iXSystems these days. I highly doubt any court or IP Lawyer with anything beyond spurious avarice would have any interest in even entertaining such a lawsuit; larger firms have tried, and failed in litigation in parallel realms already (e.g. SCO vs IBM) to no meaningful end other than probably lining the wallets of some attorneys, not programmers.

  2. By Billy Larlad (69.178.115.77) larladtech@gmail.com on

    This sounds great. Good work, devs! The ports team deserves a lot of credit for continually keeping ports up-to-date with OpenBSD's latest security features. A never-ending job.

  3. By Sebastian Rother (79.247.132.99) on

    I completly angree to this step (except of the trolls (of BOTH sides) who talk about who invented what bullshit first....

    But consider: The BASE OS is capable to do what exactly?

    1. run a basic Mail Server
    2. run a very BASIC webserver (no *.php and so, even if SSI could get included via a CGI (thttpd as example) it comes with no native support of any way)
    3. other basic Services (dhcp, ntp and co)
    4. You get the point, don't you.. :)


    What does it lack?

    A basic mail application (well "mail" exists but I mean a Client where you can connect to an IMAP(s)/POP3(s) Server). Any kind of Browser... Well you get the point again I think....

    So I (ME, the person I am.. ) consider this Change as a step ahead but the Project needs to take care of other things from Ports even if this is not included in the BASE-System! People do use Dovecot, people do use exim/sendmail... they might use another ftpd because the one in Base lacks features (like ftps?! Security "first", huhu?! Why is ftpd not in the ports anyway (it lacks "Security"..), Auth against ldap even ldapd is included.. If you found some critic here you can keep it and take care of it until it grows to some logic flaw! *sacasm* :))


    But all this needs manpower or donations!

    Since manpower can get bought (you pay somebody to do XYZ) every donation counts! So get to your Boss, explain them how much you use OpenSSH or other things the Foundation supports and ask them to donate.... for example.

    This is a major step ahead even if people not familiar with Security or programming simply WONT know about the benefits! Those people wont know why/what/how something changed! They care about their Dovecot or Desktop... and now it might crash or not work anymore!

    If the Project (OpenBSD) is serious about this step: You need to take care about 3rd party applications, you need manpower....

    You could Co-Op with other Projects. NetBSD, Bitrig (Yeah, even Theo might not like it)... FreeBSD/DragonflyBSD.. all BSD would basicaly PROFIT if no application violates the new default...

    They don't have to adopt the implementation OpenBSD uses but they would all profit to fix such stuff so a Co-Op might be benefitial even if this might be a "dream".


    Just my considerations... :-)


    Kind regards,
    Sebastian Rother

    1. By Anonymous Coward (88.64.186.150) on

      > If the Project (OpenBSD) is serious about this step: You need to take care about 3rd party applications, you need manpower....

      That has always been the case. Implement a mitigation, work with upstream (3rd party software) to get the codebase to work/improve. Wash, rinse, repeat.

      And yes manpower and/or donations are always needed.

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]