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, 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 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.