[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180530130108.GA22982@openwall.com>
Date: Wed, 30 May 2018 15:01:08 +0200
From: Solar Designer <solar@...nwall.com>
To: owl-users@...ts.openwall.com
Subject: Re: Owl update
Hi Daniel,
Thank you for commenting on this.
On Wed, May 30, 2018 at 10:01:30AM +0200, Daniel Cegie??ka wrote:
> Let's start from the beginning. Why did you start Owl? I remember an
> interview with you (2002 or 2003). 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.
Yes. This was in reference to our use of other distros in late 1990s.
We switched to Owl in 2001 or so.
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. Actually, not even SSH was part of
a typical Linux distro when we started work on Owl, so at first Owl was
also more usable to us out of the box.
Then other distros progressively got more functionality built-in. 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.
After my security audit of OpenVZ in 2006, we also started using Owl
along with OpenVZ kernels, both on "hardware nodes" and in "virtual
environments" (now called containers). We made this integration
official in Owl-current in 2009 and in Owl 3.0 release in 2010. 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.
> Owl was supposed to be secure out of box.
> During all these years, a very unique and secure userland was built as
> part of the Openwall project. The knowledge and experience that
> Openwall brings is even more valuable ("bringing security into open
> environments"). But can other Linux distributions be able to use Owl's
> experience? I do not think so. Even if they try, sooner or later they
> spoil everything by adding more suid files. Owl's userland is
> therefore very unique.
Yes. We've been worrying about and dealing with problems that would
seem very minor in most other distros' userlands because they have
bigger problems anyway. For example, we worked hard to remove the SUID
bit from passwd(1), whereas they process arbitrary programs' crash
dumps automatically with large and complicated tools running as root.
> 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) and into a few upstream projects (e.g., into ISC/Vixie Cron via
OpenBSD's reimplementation of the same approach).
My little cooperation with Salvatore is about the kernel, and about
stuff that either I did before starting work on Owl (the FIFO
restrictions date back to -ow patches for 2.0.x kernels in late 1990s),
that I experimented with separately from Owl even if during and due to
Owl development (my mentions of finding unsafe file accesses in older
Postfix using an LKM), or that I was just imagining now (the O_CREAT and
other file access safety policy ideas) and that needs to be better
tested before possibly being proposed upstream (this is where a
revitalized Owl with a newer kernel could help by being a playground for
such testing).
> 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? Also,
what other kernels?
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. This also makes sense from a
security standpoint: newer kernels tend to contain new vulnerabilities,
whereas RHEL7 is already mature.
I think OpenVZ 7 doesn't support ARM64, unfortunately. So it'd be more
work and more testing for us to add such support with those kernels.
> In the past Owl was to be based on the RSBAC[2] kernel. RSBAC still
> exists, being developed on new kernels (4.14). But I'm afraid,
> however, that it may be difficult for them to survive.
>
> SELinux is great, but unfortunately difficult to configure. AppArmor
> on the other hand is easy to use and it is more an extension of the
> DAC model, on which Owl heavily relies (eg. tcb, crontab).
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. Of course, this is apples to
oranges, and both approaches can co-exist (in fact, as I recall Docker
required AppArmor clutches to make its security model complete; I don't
know if it's still the case), but for practical purposes a sysadmin
could choose between setting up a new container for a questionable app
or trying to restrict what it can do on a shared system/container with
an app-specific policy.
I liked RSBAC and considered it for Owl when we were just getting
started with Owl. ALT Linux experimented with a hardened version of
their distro with RSBAC, and I commended them on their choice at the
time. But at this age of containers, there's just little use for that.
Now, a distro could come with pre-defined policies restricting its own
services, like Red Hat's distros do (using SELinux). However, in Owl we
wanted to better explore what can be done with traditional Unix features
and occasionally with non-optional Linux specifics first. And we did.
Red Hat mostly did not (except to the extent upstreams did - e.g., they
do have OpenSSH's privsep). So I actually find their use of SELinux
policies premature. I think they achieve less of what's actually
relevant to make the systems more secure, and with greater usability
impact (a lot of people just disable SELinux on those systems instead of
learning how to re-configure it to accommodate their uses) than we do
(for an out-of-the-box install of comparable functionality).
> What do you think about the idea to use Owl userland on newer kernels?
We always tried to support it - e.g., if someone reported an issue
running the Owl userland with the latest mainline kernel, we'd look into
it and try to fix it. However, latest kernels were never a good fit for
Owl security-wise. It just means more vulnerabilities and having to
prepare security updates more often. OTOH, it'd also provide a better
playground for testing new kernel hardening features before proposing
them upstream. One of the reasons I didn't directly submit stuff
upstream is that I always was at least one kernel branch behind for my
own uses of Linux - e.g., I was on Linux 2.0.x when mainline development
was on 2.1.x.
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.
> And which one (RSBAC, SELinux, AppArmor) in your opinion is the most
> suited to using with Owl userland? I'm interested in which solution
> you would use for yourself with Owl userland.
If you asked me in early 2000s, I'd say RSBAC. Now it's none of these.
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.
