[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 6 Jul 2018 14:30:43 +0300
From: gremlin@...mlin.ru
To: owl-users@...ts.openwall.com
Subject: Re: Owl update
On 2018-07-03 13:51: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).
It still is a container, but with separate filesystem (C.O. to the
rescue).
> While ploop might be better for security,
Very unlikely: when the VE needs to be stopped to just resize the
filesystem, that may (and should) be considered as an outage, like
caused by DoS.
> no support for simfs breaks straightforward upgrades for systems
> that currently use simfs
Ughm... How long you were keeping away from administration except
of your own hosts? :-)
There's no upgrades: once a new host is set up, the VEs are migrated
there and, finally, the old host gets a clean install of a new system.
> 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.
VEs are notably faster (there's no hypervisor), but I know only one
implementation where getting root access inside of container doesn't
cause getting root access to the host, and that's OpenVZ.
> I ran this Twitter poll a couple of days ago:
> Poll: Openwall GNU/*/Linux (Owl) development has been on hold
> for some years. What should we do about it?
> 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)
I'd guess you have very ughm... specific subscribers there. Also, the
answers by 111 people aren't really representative (although they are
much better than nothing).
> 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.
You interpret the results incorrectly: first of all, there are 82% of
people answered who need hardened system. Out of those, almost a half
want it to be minimalistic, more than a third want a full-featured but
secure system and, finally, others want to get a minimalistic system
which could be easily extended.
> RHEL fork sounds to me like it'd attract a wider userbase (beyond
> the kind of community that saw my Twitter poll).
Obviously, all those people don't want to get yet another RHEL (there
already are two, including CentOS). Also, we can't just shift RedHat
out of their market share (it's too large), but we can perfectly fit
the areas where the people need to use RHEL (or CentOS) only because
there's no alternative (everything else is even worse).
So, what's really annoying in RHEL?
0. Redundant dependencies. Many distributions suffer of that (even
really minimalistic Owl had some), but there's real dependency hell.
1. The use of systemd. Many people keep running CentOS 6 (or Owl)
just to avoid this crap in the production environments - it heavily
increases the TCO (that parameter measured in {EUR,RUB,USD}/month,
which our customers do really understand).
2. Enormous addiction on python. Well, yum is really good, but I'd
rather use apt (as in ALT) just to avoid yet another redundant
dependency.
3. Lots of vendor locks - "if you want to do %s, you may either do
that with %s or do anyting else at your own risk".
The system without these "features" would have good chances to fire up.
> 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.
When someone needs kernel live patching, they have something done
terribly wrong.
> 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).
That means revitalizing Owl and keeping it RHEL-compatible (as much
as possible; obviously, if we'd add udev or systemd to Owl, the
resulting system would have no advantages over RHEL while being not
RHEL itself, but will have a strong disadvantage for existing users).
So the main rule should read like "first, make it usable and secure;
if there are several ways to achieve that, try to make it compatible
with RHEL".
> Alpine fork will probably attract fewer users
That's a good reason to not waste time on that.
> Also, more of our changes will probably get upstream (bringing
> up the interesting question of whether/why continue to maintain
> the fork).
There are many customers (yes, not just users, but customers) who
would really like to get at least "RHEL without systemd". Obviously
enough, RedHat doesn't care of them - but we can.
> Another good thing of going with Alpine is that it'd let us work
> more closely with the musl project.
I think musl may be interecting for embedded systems, but not for
general purpose.
> With either fork, we could support Vz7 kernels and the
> corresponding most-required userland tools (vz*, but not prl*)
> as an option.
Yet another mistake... OpenVZ can't be an option - we had it ready
out-of-the-box for over 10 years, and that was one of the Owl's
strongest advantages.
Also, almost everything of http://gremlin.people.openwall.com/SRPMS/
was built in a clean environment produced by `vzctl create` and
immediately deleted by `vzctl destroy` after a successfull build.
> 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?
Who cares? The Docker is not a containerization solution - it's
just a method of producing incredibly working environments with
lots of crocks and hacks, and distributing these environments
among production servers. That has nothing to deal with security
or even reliability.
--
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.
