Date: Tue, 3 Jul 2018 13:51:08 +0200 From: Solar Designer <solar@...nwall.com> To: owl-users@...ts.openwall.com Cc: Vasily Averin <vvs@...tuozzo.com>, Natanael Copa <ncopa@...inelinux.org>, Rich Felker <dalias@...c.org> Subject: Re: Owl update On Fri, Jun 08, 2018 at 08:02:15AM +0300, gremlin@...mlin.ru wrote: > On 2018-05-30 15:01:08 +0200, Solar Designer wrote: > > 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. I have to agree. With ploop, it's neither here (containers) nor there (VMs). While ploop might be better for security, no support for simfs breaks straightforward upgrades for systems that currently use simfs and it brings usability drawbacks much like VMs would, yet without switching to VMs. So the point of spending effort on migrating from simfs to ploop is moot - that effort could as well be spent on migration to VMs. I ran this Twitter poll a couple of days ago: https://twitter.com/solardiz/status/1013381633305608192 Poll: Openwall GNU/*/Linux (Owl) development has been on hold for some years. What should we do about it? If you have no preference or yours is not listed, don't vote. If you have other ideas, reply. Context: http://www.openwall.com/Owl/ http://www.openwall.com/lists/owl-users/2014/12/30/1 http://www.openwall.com/lists/owl-users/2018/05/30/2 18% Discontinue the project 15% Revitalize, release Owl 4 28% Make hardened RHEL7+ fork 39% Make hardened Alpine fork 111 votes (in 24 hours mostly during a weekend) So it appears that at least among this wider community (mostly not current/prior Owl users, but some of the people who follow me and those who chose to retweet this on Twitter) simply revitalizing Owl is the least popular option, and forks of other distros are the most popular (67% combined for one of the two offered fork ideas). I'm also surprised by how popular the idea of forking and hardening Alpine is. As I wrote in a tweet reply: "Deciding on the existing project's fate, the first question is whether and how to meaningfully reuse Owl's userland hardening (code, expertise, experience) in this or another project. We also need replacements for the existing Owl installs." The two fork ideas I offered sort of fit these goals. With either of them, we can focus on providing a hardened base system, reusing the upstream distro's repositories (or CentOS in case of RHEL) for the many extras. We'd also achieve that by revitalizing Owl and offering support for CentOS 7 and Alpine, etc. in containers, but apparently being a fork of something better-known sounds more attractive to the wider community. Also, with our own hardened forks the base system would be hardened even when used in containers, whereas with mere support for those other distros in containers the hardening wouldn't be present in there. RHEL fork sounds to me like it'd attract a wider userbase (beyond the kind of community that saw my Twitter poll). It also sounds like it'd more likely allow for monetization e.g. through revenue sharing by existing kernel live patching services and cloud hosting providers. However, I'm concerned how small we'd be able to make the base system that we (re)build ourselves - I suspect that even the installer alone will bring in plenty of dependencies (or do we just reuse CentOS binary packages in there?) OTOH, our existing hardening changes are probably easier to include in a RHEL fork (uses RPM, has glibc, Linux-PAM, etc.) than in an Alpine fork (has its own package manager, uses musl). Alpine fork will probably attract fewer users and will require re-working some of our hardening changes (e.g., some of what we have in pam_tcb will probably need to become part of the passwd program?), but the resulting system will be more in line with Owl concepts - smaller and more secure. Also, more of our changes will probably get upstream (bringing up the interesting question of whether/why continue to maintain the fork). Another good thing of going with Alpine is that it'd let us work more closely with the musl project. We're already hosting the musl mailing list, and musl already supports Owl's /etc/tcb (but no distro uses that yet?) For Alpine, we'll possibly end up being the ones to implement package signature verification, although I'm not up to date on that - do they possibly have that already? With either fork, we could support Vz7 kernels and the corresponding most-required userland tools (vz*, but not prl*) as an option. As I understand, Alpine is now the default distro for Docker containers, but I have no idea if it's also well-suited as a host for those or not. I would guess so? Alexander
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.