Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 8 Jun 2018 08:02:15 +0300
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[1], 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

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.