LWN: Comments on "Tightening security: not for the impatient"

Tightening security: Time to prioritize it!!

dlang — 2012-08-21T19:34:47+00:00

for people who put security first, ahead of everything else, there is really only one solution

http://www.ranum.com/security/computer_security/papers/a1...

Tightening security: Time to prioritize it!!

dark — 2012-08-21T10:55:03+00:00

Well, that definition of 'properly' puts security in fourth place. It makes it an afterthought. Something that's nice to have as long as it doesn't impact the important stuff. I don't think it's likely that people who put security in first place are going to do their work that way.

Tightening security: Time to prioritize it!!

reddit — 2012-08-21T07:46:53+00:00

These guys should work on pushing their changes into the mainline kernel.

Which means doing them properly in such a way that they don't impact performance, functionality or compatibility.

Tightening security: not for the impatient

nlucas — 2012-07-23T13:15:57+00:00

The busybox project is well is aware of that and recomends a different busybox binary for suid and regular binaries.

It's easy enough to build a busybox binary implementing only the suid utils (as is to not include the suid utils on the regular binary).

Tightening security: not for the impatient

mathstuf — 2012-07-21T16:55:31+00:00

Okay, so why make the binary SUID after hardlinking? Since that makes *every* one of those binaries SUID now. If it's something like toybox, I don't want sed to be SUID even if mount is hardlinked to it. Seems like there's a case for having a separate SUID instance that those programs link to.

Tightening security: not for the impatient

anselm — 2012-07-21T11:30:54+00:00

Hard-linked files do share the same permissions – permissions are stored on the file's inode and hard links are just extra directory entries that point to the same inode.

Linux will not let you create a hard link to an executable file that is marked suid but doesn't belong to you. Making hard links to a file that you own yourself is fine regardless of whether that file is suid or not, and does not impinge on the suid status of the file.

Tightening security: not for the impatient

mathstuf — 2012-07-20T23:41:07+00:00

I seem to have run across the problem that hardlinked files all shared the same permissions. Are the tests we ran for that missing something or is it just suid that is special?

Tightening security: not for the impatient

nybble41 — 2012-07-17T15:18:56+00:00

That should still work, so long as you create the links _before_ marking the binary as SUID. You could look at the reference count to ensure that there are no "rogue" links at that point. Once it's marked SUID, no new hard links could be created without first clearing the SUID bit.

Tightening security: not for the impatient

nlucas — 2012-07-17T09:29:31+00:00

It might break current busybox installations. Multiple suid binaries are linked to the same binary.

But I agree with you that it's a reasonable breakage.

Tightening security: Time to prioritize it!!

spender — 2012-07-13T02:45:52+00:00

In that case, sorry -- I shouldn't have assumed. FWIW you do a good job backporting with much attention to detail. My comments were more about merging of security features as opposed to fixes for a particular bug. Features generally require ongoing maintenance and re-evaluation.

-Brad

Tightening security: Time to prioritize it!!

BenHutchings — 2012-07-13T01:36:08+00:00

In fact just yesterday I had someone on the forums waste my time trying to get help compiling his "grsecurity" kernel that turned out to be a 2 year old Debian source of it.

Not an official Debian package, of course.

BTW, instead of making snide remarks, might your time be better served backporting some more missing security fixes to 3.2? ;)

My remark was intended more as a joke that it's very easy to satisfy people who want me (or rather us) not to work on something. Less funny when it has to be explained, I suppose. As for backporting security fixes, I try, but surely you consider me incompetent to do so?

Tightening security: Time to prioritize it!!

spender — 2012-07-12T12:26:09+00:00

Ben seems to be referring to my only public comment on the Debian list regarding packaging grsecurity. For the others reading, here's my comment in its entirety:
http://lists.debian.org/debian-kernel/2012/01/msg01165.html

Anyone is free to do what they want, of course. I just don't recommend the use of such kernels, as over the years I've noticed several things:

1) Our development is very active, yet any 3rd-party packaging has always lagged (often quite badly). In fact just yesterday I had someone on the forums waste my time trying to get help compiling his "grsecurity" kernel that turned out to be a 2 year old Debian source of it.
2) Security isn't obtained by lifting individual features, and you can't just toss some code into a codebase and claim it works as intended just because it applies cleanly. I'll be giving a talk in October at H2HC where in part I'll talk about some security features that were ripped from grsecurity and submitted upstream, then neglected to the point where they no longer do what they claim.
3) When it comes to security features, I argue the same as in Plato's "Ion", that a security researcher with kernel development experience would know best how it should be merged to preserve its integrity. Not a kernel developer lacking security knowledge, and definitely not someone just testing to see if two codebases compile when merged.

I don't think any of the above is unreasonable. BTW, instead of making snide remarks, might your time be better served backporting some more missing security fixes to 3.2? ;)

-Brad

Tightening security: not for the impatient

philomath — 2012-07-12T11:06:27+00:00

Disabling links to suid files seems very reasonable, and will most probably break nothing sane.

Tightening security: not for the impatient

nybble41 — 2012-07-11T22:44:48+00:00

> ... in some filesystem configurations a malicious user could use hard links to make 'backups' of setuid executables in the expectation that one of them would later turn out to be exploitable.

Some other reasonable workarounds for this issue would be to clear the setuid bit before replacing a setuid executable, to restrict setuid executables to a dedicated filesystem with no non-superuser write access, or to prevent creating links to files with setuid enabled.

Or we could drop setuid entirely and go with something more like PolicyKit, which isn't affected by hard links, thus making the root -> user transition a one-way street.

Tightening security: not for the impatient

BenHutchings — 2012-07-11T21:31:27+00:00

POSIX also allows pretty much any operation to be denied due to security policy.

Tightening security: not for the impatient

BenHutchings — 2012-07-11T21:30:31+00:00

Perhaps link() should be allowed to work if the user has read or write access to the file? Making a hard link to a file that cannot be read by the current user does seem to have little purpose.

If a setuid executable turns out to be exploitable, the sysadmin will (hopefully) upgrade it to a fixed version quickly. But in some filesystem configurations a malicious user could use hard links to make 'backups' of setuid executables in the expectation that one of them would later turn out to be exploitable. The hard link restrictions prevent this.

Tightening security: Time to prioritize it!!

BenHutchings — 2012-07-11T21:21:22+00:00

spender doesn't want distributions to package grsecurity, as its security improvements might be compromised by other patches they apply. I am quite happy to oblige him in this regard.

Tightening security: not for the impatient

kevinm — 2012-07-09T03:55:40+00:00

It's not the director(ies) where the current links are that matter, it's the directory where the new link is being created that should have to be sticky for the new rules to apply.

It even makes sense, because in a sticky directory you can create hardlinks that you can't then remove, but the same isn't true of nonsticky directories.

It's also unambiguous, and the destination directory of the link already has to be looked up to create the link.

Tightening security: not for the impatient

mfedyk — 2012-07-06T19:49:32+00:00

Since most filesystems do not have a reverse reference from inode to dirents that point to them, you would either have to do a directory tree walk or hope it's already cached in the dcache, which would lead to immeasurable amounts of fun. That, or it would depend on which dirent was used to look up the inode.

No, this hard link change could not be related to directory sticky bit because multiple directories could point to the same inode (hard links).

That said, it would be acceptable IMO if it was activated with a mount option.

Tightening security: not for the impatient

kevinm — 2012-07-05T02:18:51+00:00

It's correct that the symlink behaviour change doesn't violate POSIX, because it's limited to directories with the sticky bit set and the sticky bit isn't specified by POSIX at all.

The hardlink behaviour change would though, unless it too is limited to directories with the sticky bit set - is that the case?

Tightening security: not for the impatient

ScottMinster — 2012-07-03T22:01:24+00:00

a hard link to a file can only be created if the user owns the file or has write access to it

This doesn't sound too good. Where I work, we have applications that regularly create hard links to files just for reading. The reason we do this is in case the file is replaced by a new version while it is being read. This shouldn't be a problem on most file systems, but NFS has given us trouble in the past, and we're often using NFS filesystems.

The code follows the pattern of link(), open(), and unlink(). The NFS server will keep the unlink'ed file, and more importantly the NFS key (or whatever its called) around so the original file's contents can be read, even if the file is replaced with a new version (through writing to a temporary file and renaming).

While the code is robust enough to fallback on opening the original file instead of a temporary link if it cannot make the link (often happens if the directory itself is not writable), it would be annoying to lose this feature. We've had weird race conditions in the past on NFS without this logic.

Perhaps link() should be allowed to work if the user has read or write access to the file? Making a hard link to a file that cannot be read by the current user does seem to have little purpose.

Tightening security: Time to prioritize it!!

man_ls — 2012-07-01T14:35:47+00:00

Granted, the one-liner was a bit misleading; the same comment could have been made for many other things and be equally meaningless. Just for fun:

I have no familiarity with github, but that their entire site seems to be Rails-based made me wince a little.
I have no familiarity with Red Hat, but that their entire distro seems to be Linux-based made me wince a little.
I have no familiarity with eBay, but that their entire site seems to be IIS-based made me wince a little.

(The last one made me wince too, but hey.)

Anyway I think you (Brad Spender) can do better than insult someone in public. This kind of derision tells more about you than about the original poster.

Tightening security: Time to prioritize it!!

spender — 2012-07-01T12:40:39+00:00

You should look again at the comment I was actually replying to (it seems you paired it up with a different one). If you think *that* idiotic one-liner was "reasonable", more power to you.

-Brad

Tightening security: Time to prioritize it!!

roblucid — 2012-07-01T11:52:59+00:00

grsecurity has been offered by some distro's and not others, so the original point made in comment was reasonable; it does not have universal acceptance. There are often competing approaches and implementations of ideas, some developers work better with the LKML community than others so tend to have code accepted where others have failed.

The last sentence was not necessary, a personal comment detracting from the technical point point.

Tightening security: Time to prioritize it!!

spender — 2012-06-30T01:31:06+00:00

I suppose you prefer the OpenBSD camp and their "security through complete lack of features"? What kind of security system would it be if it couldn't withstand running the same software nearly everyone else does?

Regardless, it seems to be working out a lot better for us than whatever kernel.org has been running ;)

It's clear you have no familiarity with grsecurity: having your head in the sand for a decade speaks volumes about your security knowledge.

Not really sure why people like yourself feel the need to reply publicly just to expose your own ignorance to the world.

-Brad

Tightening security: Time to prioritize it!!

utoddl — 2012-06-29T19:14:46+00:00

Okay, I have no familiarity with grsecurity, but that their entire site seems to be php based made me wince a little.

Tightening security: Time to prioritize it!!

spender — 2012-06-29T14:50:53+00:00

> We should be searching for those mechanisms

For those without horse blinders:
http://www.grsecurity.net/

Kick your shoes off, prop your feet up, and have a margarita or two. Reward yourself for a job well done!

-Brad

Tightening security: Time to prioritize it!!

david.a.wheeler — 2012-06-28T15:31:18+00:00

Congrats to Kees Cook, who patiently managed to get this in.

But the slow pace of getting security-tightening mechanisms into the kernel is embarrassing.

It's absurd to wait until "all applications as libraries are perfect" as a security strategy. We need a "plan B". A kernel cannot prevent all errors from becoming security vulnerabilities, but where the kernel can reasonably prevent them or reduce their effects, it should do so.

We should be making security-tightening measures a high priority, not something that's done as a last resort. We should be searching for those mechanisms, not trying to prevent their inclusion.

Tightening security: not for the impatient

ortalo — 2012-06-28T14:30:35+00:00

Time and patience is one aspect of the issue of course. However, it seems to me that this aspect is also a consequence of design priorities.

Should you pointing these very long delays of elementary improvements lead us to think that reconsidering the priority of security with respect to other issues in the overall development would be desirable?

If that's the case, you have my full support - even though it also seems to me that nowadays the security of user-level programs is becoming the urgent issue.