Date: Fri, 8 Jun 2018 08:02:15 +0300 From: gremlin@...mlin.ru To: owl-users@...ts.openwall.com Subject: Re: Owl update On 2018-05-30 15:01:08 +0200, Solar Designer wrote: Sorry for a late reply... >> You said you started the Openwall project because every time you >> set a new server, you had to spend a lot of time to secure it. > With Owl, time had to be spent on installing use case specific > software on top of it. This was no different compared to our uses > of distros of late 1990s, where such software was also either > not packaged or at least not in the way we wanted it anyway. Alas, this software became almost useless very quickly. > Then other distros progressively got more functionality built-in. However, most of those (I can't tell surely for all) are unusable out-of-the-box because the developers have no idea on who are their users and what they really need. > Owl without even a web server in it started looking especially > weird to many prospective users. We had our own set of packages > for use on top of Owl, eventually called OwlX, but we never > brought it to a state where we'd be comfortable releasing and > maintaining it for the general public. The same mistake here: s/general public/system administrators/ These people just want the system to perform a relatively small set of tasks and be convenient with setting it up to do that. > After my security audit of OpenVZ in 2006, we also started using > Owl along with OpenVZ kernels > With this, Owl made more sense for use by others: yes, its package > set was still very limited, but that was actually good for use on > "hardware nodes", where other distros could also be run in VEs aka > containers. And with that we've stucked on 2.6 kernels... well, I've successfully moved to 2.6.32-vz which was still supported even by a quite recent glibc-2.26, and that allows me to continue using my own Owl derivatives on my servers. >> Regarding to Owl's future. Currently, thanks to your cooperation >> with Salvatore Mesoraca, more and more solutions developed >> for the Owl's kernel begin to go to linux. > That's not how I see it. As you correctly noted above, Owl was/is > primarily about the hardened userland. Some of the things we tried > out in Owl got into a few other distros (especially ALT Linux's, > so it's also where we might take forward-ported patches from > if we revitalize Owl) ALT was started as (and still is) a desktop system. After many years of development it become "dirty", having many redundant dependencies (when I recently tried to install LibreOffice on my workstation, it attempted to pull gcc-fortran as a chained dependency). That could be tolerated on a desktop, but will definitely be inacceptable for servers. That means, even just taking patches would likely take much time. >> I wonder if it would be sensible to use Owl userland also on >> other kernels. This would allow better use of the new hardware >> (eg. CPU's, amr64). > Sure, but who would be the users and why would they prefer Owl? 1. servers 2. embedded systems, including network hardware > Also, what other kernels? I'd guess: recent 4.* > Given what Owl already is and our own primary use cases for it, > the currently possible migration path is to OpenVZ/Virtuozzo 7 > kernels, which are based on RHEL7's "3.10" kernels. After the drop of vzquota (simfs) in favour of ploop, the OpenVZ had become almost useless. On 2018-04-24 I tried asking the people from OpenVZ team whether there would be UBC and simfs support in the newer 4.* (4.14-based) kernels, but got no answer - not even a single fuqoff. > This also makes sense from a security standpoint: newer kernels > tend to contain new vulnerabilities, whereas RHEL7 is already > mature. Newer kernels do support newer hardware. Without that, the kernel is useless. > I see little point, other than "marketing", in introducing any of > that to Owl at this time. We need containers anyway, they're most > mature in OpenVZ/Virtuozzo, and upgrading within the same container > technology is most straightforward. Containers are easier to > use and reason about than policies with a single larger system. That applies to both virtualization techniques, VPS and VDS. > We could possibly develop a semi-stable branch with OpenVZ 7 > kernels and a current branch with latest mainline kernels, but then > the current branch would lack support for OpenVZ containers and > wouldn't be able to build vz* packages (unless we build it/them > with OpenVZ kernel headers). This would have some advantages - > "marketing" ("yes, we have a branch with latest kernels"), a > playground for submitting kernel patches upstream, and making our > userland ready for newer OpenVZ kernels as well (perhaps based > on RHEL8 and on). However, it would also be hackish and it'd > interfere with our usual approach of turning a matured current > branch into a stable branch. That's normal: even being "hackish", that would decrease the TCO and, therefore, could attract more customers (not just users). -- Alexey V. Vissarionov aka Gremlin from Kremlin GPG: 8832FE9FA791F7968AC96E4E909DAC45EF3B1FA8 Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.