[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
