Solar Designer on Openwall

Demonfly writes to tell us that Solar Designer, who some would argue is one of the more respected security experts on the net, took the time to answer a few questions about the future of Openwall, the security enhanced GNU/Linux distro. From the interview: "There's real demand specifically for security-enhanced Linux systems. Linux is widespread, it has good hardware support, there's a lot of software available for it (including some commercial packages), and there are system administrators with specific Linux skills. Of course, OpenBSD and other *BSDs have their user bases, too - and people are working on the security of those systems. No, Linux (the kernel) is not a better choice than *BSDs security-wise. But it is not substantially worse either."

Comments

Solar Designer on Openwall

[BigZaphod]

The title of this news item had me thinking it was some kind of cool new transparent solar cell for houses or something. That'd be pretty cool. Too bad it's just about Linux...

Re:Solar Designer on Openwall

[funpet]

No silly, the creator of the sun is sitting like Humpty Dumpty on an open wall.

Real question

[Spazmania]

The real question is: When are you going to release a set of patches for Linux 2.6?

The openwall patches for 2.4 do the following three really useful things. Hardware compatibility is pushing me to 2.6 but I'd sure like to have the patches:

Non-executable stack (defeats most buffer-overflow attacks)
Restricted links and fifos in /tmp
Restricted /proc

Ask the good folks a sdf.lonestar.org about Linux.

[ivi]

  I seem to recall reading that SDF -had- Linux, in a past life,
  but - after an intrusion - -now- use NetBSD or the like.

  They'd surely have something useful to say about Linux v BSD
  security.

  Does anybody know any of their admin's of the times to ask?

  FYI: sdf.lonestar.org is a long-time "free" Shell provider
            (I have NO pecuniary interest in their organisation)

openwall

[NynexNinja]

I respect Solar Designer, even though at the time of the initial development of these patches, most of these features were available as seperate patches from various groups of hackers -- Solar Designer is credited for integrating them into one jumbo patch.. That being said, he never put out patches for Linux 2.6, maybe due to his own stubborness towards the difference between a "production" and "beta" kernel release -- who knows.

It is because of this that other projects were allowed to flourish, namely the grsec jumbo patch. I think most people for the last several years have pretty much abandoned using (or even thinking of using) the openwall set of patches when other more feature-rich, updated patches exist and have existed for many years now.

Re:openwall

[in10d]

> more feature-rich, updated patches exist
Yes.
That's why many (me included) use openwall patches when rolling 2.4 kernels.
Feature-rich means "may-be-buggy" (or at least harder to review and apply).

I think trust is the keyword for this situation.
I trust openwall.
Their patches work and do only a few simple but important things.
This is the Right Way in unix world.

got it already

[r00t]

The non-executable stack is in 2.6.xx already. It's activated for normal executables that have been compiled with a recent compiler.

Rather than restricting /tmp, you can now use the unshare() system call with CLONE_NEWNS to give every user their own private /tmp. You can also just restrict /tmp via an LSM (Linux Security Module, like SE Linux or RSBAC)

You can restrict /proc with an LSM too.

Re:got it already

[Spazmania]

The non-executable stack is in 2.6.xx already.

Then why does the stacktest.c program from openwall succeed in simulating a buffer overflow in SuSE Enterprise 9 with kernel 2.6.15.6?

You can restrict /proc with an LSM too.

Yeah? Which?

Re:got it already

[r00t]

You probably compiled stacktest.c with an old toolchain. Perhaps SuSE didn't enable the non-executable stack. Maybe your hardware doesn't support the NX bit.

SE Linux should do fine for restricting /proc.

Re:Disagree

[moro_666]

kernel security this and kernel security that. sure it gives you something, but it doesn't really protect you from the dumb administrators and even more dummy users.

  what i'd gladly see in the linux world, userspace transparent jailing (meaning i could run my applications without endangering the rest of the system). i could give the application read access where it needs to read, hide files that it doesn't need to know about, and not let it write a thing except the directory that it runs in. sure running another linux inside your linux does the trick, but the regular really can't do it, it requires root permissions and a nice bucket of time (that most of us don't really have in hand). ye, and memory access control wouldn't hurt either (meaning the app could only read and write from the memory that i allow it too, not what it thinks it should read/write). and if you've got a really nice application/preloadable_lib that already provides it, pleas be just kind enough to reply this in here.

  enhancing only the kernel isn't enough, we need sandboxes around our buggy apps. kernel doesn't really have an idea that a dummy php script could save an uploaded file and execute it with eval ( 'system (/tmp/foobar) '); or smth in the way. but a properly configured sandbox would know it and could prevent it.


  i have a perl script here , around 40 lines long, that takes a linux box down to halt from the "nobody" user account, within half an hour (tested both, 2.4 and 2.6 series). that's not what i'd define as security, do you ?

Re:Disagree

[booch]

You should look into FreeBSD's systrace functionality. It looks a little easier to set up than a chroot jail, but is more fine-grained, and concerns more than just file access. As far as I know, Linux doesn't have anything like it though. (I wish it did!)