Kernel Traffic #295 For 3 Feb 2005

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10/2.6.10-mm1

• Added new bk-kconfig tree from Sam
• The bk-usb tree has been dropped due to a tendency to oops.
• Lots of stuff.

OSS itself changed behaviour over time (2.2 to 2.4) ALSA has merely caught up with the newer OSS behaviour and the new behaviour is correct.

If you want to find out if the interface is busy open it. If you want to do it portably open it with O_NDELAY.

It was discussed on alsa-devel in November. Unfortunately, I can't find ML archive any longer...

The blocking behavior of OSS is a feature which is nowehre defined. Some OSS drivers open in the blocking mode and some don't. So, apps shouldn't depend on this feature.

We had implemented OSS emulation in the blocking manner since we intepreted the POSIX definition in that way. But Linus pointed out that it's a misreading.

BTW, you can enable the blocking mode again via module/boot option. See OSS-Emulation.txt.

if you want the excruciating details, here are some pointers. It's a long thread, and unfortunately the threading is a little broken.

Here's a link to the technical part:

http://sourceforge.net/mailarchive/message.php?msg_id=10008900

And here's the rant that started it:

http://sourceforge.net/mailarchive/message.php?msg_id=10014826

With split interfaces (machine-/human-readable) as proposed a few months ago, we wouldn't need to clutter /proc with such cruft. We could simply add the obvious field to /proc/maps and add another field to nproc.

Using procfs for both humans and software means over time it will get worse for _both_ sides, and switching to a saner solution won't get cheaper, either. I still believe we should bite that bullet now.

Well, it goes back to just what wli freed 2.6 from, and what we scorned clameter for: a costly examination of every pte-slot of every vma of the process. That doesn't matter _too_ much so long as there's no standard tool liable to do it every second or so, nor doing it to every single process, and it doesn't need spinlock or preemption disabled too long.

But personally I'd be happier for it to remain an out-of-tree patch, just to discourage people from writing and running such tools, and to discourage them from adding other such costly analyses.

Potentially quite useful, perhaps. But I don't have a use for it myself, and if I do have, I'll be content to search out (or recreate) the patch. Let's hear from those who actually have a use for it now - the more useful it is, of course, the stronger the argument for inclusion.

Available at http://ep09.pld-linux.org/~mmazur/linux-libc-headers/

Changes:

• updated to 2.6.10
• switched to using svn and now ChangeLog is back :)
• some minor changes here and there (made some headers ansi C compatible)

Two weeks after 2.6.10, but you can blame Linus for releasing 2.6.10 just before Christmas.

Like I've said two months ago - my scripts for testing new versions now do separate asm-i386-ansi and asm-i386-noansi checks, so any ansi degradation in linux or asm-i386 (like the one from 2.6.9) won't go unnoticed.

One more thing - llh is now officially one year old (first commits are from December 2003). That's a long time for any hack to live. Especially a hack this big and one that even has a couple of vendor specific variants. A couple of discussions took place concerning this matter (in the last one Linus even said, that he'll be accepting patches) and still I see no movement. I'd really like to see glibc guys figuring out a way not to duplicate definitions and structures from linux and starting to submit patches. That'd be a really good (and much needed - glibc's and linux' headers conflict in lots of ugly ways) first step.

There seems to be some confusion in certain quarters as to the proper procedure for reporting possible kernel security issues. REPORTING-BUGS says send bug reports to the maintainer of that area of the kernel. However, what about areas for which a maintainer is not listed? (e.g. VM) It seems that some take that to mean send it directly to Linus and if you don't hear something back quickly, release an exploit to the wild.

So what is the preferred procedure and is it documented somewhere? Should it be made more prominent?

Good question. The preferred procedure depends on your viewpoint on disclosure

vendor-sec@lst.de is a cross vendor security list and a good place for stuff. It will deal with both public and date embargoed security information. security@[your-vendor] should work for most responsible vendors and may be more appropriate if it involves a vendor kernel that may have bugs not in the base tree.

For stuff in -bk kernel snapshots and the like that isn't in the production kernels then I'd start by mailing Linus/(Andrew for -mm) or the list.

This same discussion is taking place in a few forums. Are you opposed to creating a security contact point for the kernel for people to contact with potential security issues? This is standard operating procedure for many projects and complies with RFPolicy.

http://www.wiretrip.net/rfp/policy.html

Right now most things come in via 1) lkml, 2) maintainers, 3) vendor-sec. It would be nice to have a more centralized place for all of this information to help track it, make sure things don't fall through the cracks, and make sure of timely fix and disclosure.

In addition, I think it's worth considering keeping the current stable kernel version moving forward (point releases ala 2.6.x.y) for critical (mostly security) bugs. If nothing else, I can provide a subset of -ac patches that are only that.

I volunteer to help with _all_ of the above.

I'd very happy with a "private" list in the sense that people wouldn't feel pressured to fix it that day, and I think it makes sense to have some policy where we don't necessarily make them public immediately in order to give people the time to discuss them.

But it should be very clear that no entity (neither the reporter nor any particular vendor/developer) can require silence, or ask for anything more than "let's find the right solution". A purely _technical_ delay, in other words, with no politics or other issues involved.

Otherwise it just becomes politics: you end up having security firms that want a certain date because they want a PR blitz, and you end up having vendors who want a certain date because they have release issues.

Does that mean that vendor-sec would end up being used for some things, where people _want_ the politics and jockeying for position? Probably. But having a purely technical alternative would be wonderful.

There's already vendor-sec. I assume they follow RFPolicy already. If it's just another vendor-sec, why would you put up a new list for it?

In other words, if you allow embargoes and vendor politics, what would the new list buy that isn't already in vendor-sec.

When I saw how vendor-sec worked, I decided I will never be on an embargo list. Ever. That's not to say that such a list can't work - I just personally refuse to have anything to do with one. Whether that matters or not is obviously an open question.

Of course it matters Linus - vendors need time to prepare their updates. You can't ignore that, and you can't "have nothing to do with it".

You seem to dislike the way embargos have been done on vendorsec, fine. They can be done on a different way, but you have to understand that you and Andrew need to follow and agree with the embargo.

How you feel about having short fixed time embargo's (lets say, 3 or 4 days) ?

The only reason for this is to have "time for the vendors to catch up", which can be defined by the kernel security office. Nothing more - no vendor politics involved.

It is a simple matter of synchronization.

Please realize that I don't have any problem with a short-term embargo per se, what I have problems with is the _politics_ that it causes. For example, I do _not_ want this to become a

"vendor-sec got the information five weeks ago, and decided to embargo until day X, and then because they knew of the 4-day policy of the kernel security list, they released it to the kernel security list on day X-4"

See? That is playing politics with a security list. That's the part I don't want to have anything to do with. If somebody did that to me, I'd feel pissed off like hell, and I'd say "screw them".

But in the absense of politics, I'd _happily_ have a self-imposed embargo that is limited to some reasonable timeframe (and "reasonable" is definitely counted in days, not weeks. And absolutely _not_ in months, like apparently sometimes happens on vendor-sec).

So if the embargo time starts ticking from _first_ report, I'd personally be perfectly happy with a policy of, say "5 working days" (aka one week), or until it was made public somewhere else.

IOW, if it was released on vendor-sec first, vendor-sec could _not_ then try to time the technical list (unless they do so in a very timely manner indeed).

I'm not saying that we'd _have_ to go public after five days. I'm saying that after that, there would be nothing holding it back (but maybe the technical discussion on how to _fix_ it is still on-going, and that might make people just not announce it until they're ready).

Btw, the only thing I care about is the embargo on the _fix_.

If a bug reporter is a security house, and wants to put a longer embargo on announcing the bug itself, or on some other aspect of the issue (ie known exploits etc), and wants to make sure that they get the credit and they get to be the first ones to announce the problem, that's fine by me.

The only thing I really care about is that we can serve the people who depend on us by giving them source code that is as bug-free and secure as we can make it. If that means that we should make the changelogs be a bit less verbose because we don't want to steal the thunder from the people who found the problem, that's fine.

One of the problems with the embargo thing has been exactly the fact that people couldn't even find bugs (or just uglinesses) in the fixes, because they were kept under wraps until the "proper date".

Quite frankly, nobody should ever depend on the kernel having zero holes. We do our best, but if you want real security, you should have other shields in place. exec-shield is one. So is using a compiler that puts guard values on the stack frame (immunix, I think). But so is saying "you can't just compile or download your own binaries, nyaah, nyaah, nyaah".

As I've already made clear, I don't believe one whit in the "secrecy" approach to security. I believe that "security through obscurity" can actually be one valid level of security (after all, in the extreme case, that's all a password ever really is).

So I believe that in the case of hiding vulnerabilities, any "security gain" from the obscurity is more than made up for by all the security you lose though delaying action and not giving people information about the problem.

I realize people disagree with me, which is also why I don't in any way take vendor-sec as a personal affront or anything like that: I just think it's a mistake, and am very happy to be vocal about it, but hey, the fundamental strength of open source is exactly the fact that people don't have to agree about everything.

it's very clear that some exploits have definitely been written by looking at the source code with automated tools or by instrumenting things, and that the exploits would likely have never been found without source code. That's fine. We just have higher requirements in the open source community.

And I do think that the same is true for being open about security advisories: I think that to offset an open security list, we'd have to then have more "best practices" than a vendor-sec-type closed security list might need. I think it would be worth it.

Ok, the big merges after 2.6.10 are hopefully over, and 2.6.11-rc1 is out there.

Lots of small cleanups, although that inevitable qlogic firmware update makes pretty much _everything_ look small in comparison.

SCSI, USB, IDE, x86-64, FRV, PPC64, ARM, input layer, ALSA, network drivers, pcmcia, knfsd, ACPI, sparse cleanups... You name it. Lots of (mostly) small updates all over the landscape.

What gets hidden in the noise of all the updates is things like the conversion to 4-level page tables by Andi Kleen and Nick Piggin. That makes us able to use the full virtual memory space on 64-bit architectures. The patches may not be very large, and in fact it was interesting to see just how smoothly it seems to integrate.

Here goes the second release candidate of v2.4.29.

It contains mainly security fixes, including backports from 2.6-ac Coverity fixes, rework of the do_brk() fixes as suggested by Linus, and a fix for the pagefault SMP race disclosed today:

CAN-2005-0001
http://www.isec.pl/vulnerabilities/isec-0022-pagefault.txt

To keep the conversation concrete, here's a pretty rough stab at documenting the policy.

Linux kernel developers take security very seriously. As such, we'd like to know when a security bug is found so that it can be fixed and disclosed as quickly as possible.

1) Contact

The Linux kernel security contact is $CONTACTADDR. This is a private list of security officers who will help verify the bug report and develop and release a fix. It is possible that the security officers will bring in extra help from area maintainers to understand and fix the security vulnerability.

It is preferred that mail sent to the security contact is encrypted with $PUBKEY.

As it is with any bug, the more information provided the easier it will be to diagnose and fix. Please review the procedure outlined in REPORTING-BUGS if you are unclear about what information is helpful. Any exploit code is very helpful and will not be released without consent from the reporter unless it's already been made public.

2) Disclosure

The goal of the kernel security contact is to work with the bug submitter to bug resolution as well as disclosure. We prefer to fully disclose the bug as soon as possible. It is reasonable to delay disclosure when the bug or the fix is not yet fully understood, the solution is not well-tested or for vendor coordination. However, we expect these delays to be short, measurable in days, not weeks or months. As a basic default policy, we expect report to disclosure to be on the order of $NUMDAYS.

I see myself as pretty extreme when it comes to my approach to security.

And I actually distrust extremes. I'm at one end of the spectrum, and vendor-sec is at the other (I'm not even counting the head-in-the-sand approach as part of the spectrum ;). Knowing that, I'd expect that most people are somewhere in between.

Which to me implies that while what I personally _want_ is total openness, that's not necessarily what makes the most sense in real life.

So I want to give people choice. I want to encourage openness. But hell, if we have a closed list with a declared short embargo that is known to not play games (ie clock starts ticking from original discovery, not from somebody elses embargo), that's good too.

Let people vote with their feet. If vendor-sec ends up being where all the "important" things are discussed - so be it. We've not lost anything, and at worst a "kernel-security" list would be a way to discuss stuff that was already released by vendor-sec.

On my understanding we are about to win several things.

I rather prefer having vendorsec NOT deal with these issues because it gives autonomy to the kernel team. It wont depend on "suspicious" criteria of embargo's - but instead have a clear written policy for embargo's.

And the timeframe, as Alan says, has to be acceptable for the vendors to generate their updates and run the QA process, otherwise things will continue to be discussed at vendorsec.

Other than that, by not "wrapping" the fixes with non descritive changelogs, we will have an official list of security problems. Hey, this is a serious operating system.

Wrapping up fixes means "disclosure" for the better informed people (the bad guys) who read the changesets, and means "lack of knowledge" for the less informed - users who dont run the latest kernel and only upgrade in case of public security issues (the majority of them?).

So the argument of "wrapping" up fixes for "better and safer code" is actually very bad if you think about it.

Once we have that, there will be a "official" list of known issues.

Those MANY who ask "I'm using v2.6.12 on my customized kernel and I can't upgrade to the latest v2.6.20 kernel, which security bugs exist that I need fixed?"

Will have an easy answer.

This is better for the Linux kernel developers, better for vendors and better for users.

Guess it's an open question. Do you agree with these basics bits?

• no guarantee
• attempt to work with reporter
• attempt to work with vendors
• goal of timely release
• retain final say
• within immediate to few weeks

Hard to put real time on it.

DRAFT

Linux kernel developers take security very seriously. As such, we'd like to know when a security bug is found so that it can be fixed and disclosed as quickly as possible. Please report security bugs to the Linux kernel security team.

1) Contact

The Linux kernel security team can be contacted by email at $CONTACTADR. This is a private list of security officers who will help verify the bug report and develop and release a fix. It is possible that the security team will bring in extra help from area maintainers to understand and fix the security vulnerability.

It is preferred that mail sent to the security team is encrypted with $PUBKEY.

As it is with any bug, the more information provided the easier it will be to diagnose and fix. Please review the procedure outlined in REPORTING-BUGS if you are unclear about what information is helpful. Any exploit code is very helpful and will not be released without consent from the reporter unless it has already been made public.

2) Disclosure

The goal of the Linux kernel security team is to work with the bug submitter to bug resolution as well as disclosure. We prefer to fully disclose the bug as soon as possible. It is reasonable to delay disclosure when the bug or the fix is not yet fully understood, the solution is not well-tested or for vendor coordination. However, we expect these delays to be short, measurable in days, not weeks or months. A disclosure date is negotiated by the security team working with the bug submitter as well as vendors. However, the kernel security team holds the final say when setting a disclosure date. The timeframe for disclosure is from immediate (esp. if it's already publically known) to a few weeks. As a basic default policy, we expect report date to disclosure date to be on the order of 7 days.

3) Non-disclosure agreements

The Linux kernel security team is not a formal body and therefore unable to enter any non-disclosure agreements.

======================================================================
NOTE: as far as I'm concerned, that's a beginning of VFS-2.7 branch. All that work will stay in a separate tree, with gradual merge back into 2.6 once the things start settling down.
======================================================================

OK, here comes the first draft of proposed semantics for subtree sharing. What we want is being able to propagate events between the parts of mount trees. Below is a description of what I think might be a workable semantics; it does *NOT* describe the data structures I would consider final and there are considerable areas where we still need to figure out the right behaviour.

Let's start with introducing a notion of propagation node; I consider it only as a convenient way to describe the desired behaviour - it almost certainly won't be a data structure in the final variant.

1. each p-node corresponds to a group of 1 or more vfsmounts.
2. there is at most 1 p-node containing a given vfsmount.
3. each p-node owns a possibly empty set of p-nodes and vfsmounts
4. no p-node or vfsmount can be owned by more than one p-node
5. only vfsmounts that are not contained in any p-nodes might be owned.
6. no p-node can own (directly or via intermediates) itself (i.e. the graph of p-node ownership is a forest).

These guys define propagation:

a) if vfsmounts A and B are contained in the same p-node, events propagate from A to B
b) if vfsmount A is contained in p-node p, vfsmount B is contained in p-node q and p owns q, events propagate from A to B
c) if vfsmount A is contained in p-node p and vfsmount B is owned by p, events propagate from A to B
d) propagation is transitive: if events propagate from A to B and from B to C, they propagate from A to C.

In other words, members of the same p-node are equivalent and events anywhere in p-node are propagated to all its slaves. Note that not any transitive relation can be represented that way; it has to satisfy the following condition:

* A->C and B->C => A->B or B->A

All propagation setups we are going to deal with will satisfy that condition.

How do we set them up?

* we can mark a subtree sharable. Every vfsmount in the subtree that is not already in some p-node gets a single-element p-node of its own.

* we can mark a subtree slave. That removes all vfsmounts in the subtree from their p-nodes and makes them owned by said p-nodes. p-nodes that became empty will disappear and everything they used to own will be repossessed by their owners (if any).

* we can mark a subtree private. Same as above, but followed by taking all vfsmounts in our subtree and making them *not* owned by anybody.

Of course, namespace operations (clone, mount, etc.) affect that structure and are affected by it (that's what it's for, after all).

1. CLONE_NS

That one is simple - we copy vfsmounts as usual

• if vfsmount A is contained in p-node p, then copy of A goes into the same p-node
• if A is owned by p, then copy of A is also owned by p
• no new p-nodes are created.

2. mount

We have a new vfsmount A and want to attach it to mountpoint somewhere in vfsmount B. If B does not belong to any p-node, everything is as usual; A doesn't become a member or slave of any p-node and is simply attached to B.

If B belongs to a p-node p, consider all vfsmounts B1,...,Bn that get events propagated from B and all p-nodes p1,...,pk that contain them.

• A gets cloned into n copies and these copies (A1,...,An) are attached to corresponding points in B1,...,Bn.
• k new p-nodes (q1,...,qk) are created
• Ai is contained in qj <=> Bi is contained in pj
• qi owns qj <=> pi owns pj
• qi owns Aj <=> pi owns Bj

In other words, mount is propagated and propagation among the new vfsmounts mirrors the propagation between mountpoints.

3. bind

bind works almost identically to mount; new vfsmount is created for every place that gets propagation from mountpoint and propagation is set up to mirror that between the mountpoints. However, there is a difference: unlike the case of mount, vfsmount we were going to attach (say it, A) has some history - it was created as a copy of some pre-existing vfsmount V. And that's where the things get interesting:

• if V is contained in some p-node p, A is placed into the same p-node. That may require merging one of the p-nodes we'd just created with p (that will be the counterpart of the p-node containing the mountpoint).
• if V is owned by some p-node p, then A (or p-node containing A) becomes owned by p.

4. rbind

rbind is recursive bind, so we just do binds for everything we had in a subtree we are binding in obvious order; everything is described by previous case.

5. umount

umount everything that gets propagation from victim.

6. mount --move

prohibited if mountpoint of what we are moving is in some p-node, otherwise we move as usual to intended mountpoint and create copies for everything that gets propagation from there (as we would do for rbind).

7. pivot_root

similar to --move

How to use all that stuff?

Example 1:

mount --bind /floppy /floppy
mount --make-shared /floppy
mount --rbind / /jail
<finish setting the jail up, umount whatever doesn't belong there, etc.>
mount --make-slave /jail/floppy

and we get /floppy in chroot jail slave to /floppy outside - if somebody (u)mounts stuff on it, that will get propagated to jail.

Example 2:

same, but with the namespaces instead of chroots.

Example 3:

same subtree visible (and kept in sync) in several places - just mark it shared and rbind; it will stay in sync

Example 4:

have some daemon control the stuff in a subtree sharable with many namespaces, chroots, etc. without any magic:
mark that subtree sharable
clone with CLONE_NS
parent marks that subtree slave
child keeps working on the tree in its private namespace.

There's a lot more applications of the same idea, of course - AFS and its ilk, autofs-like stuff (with proper handling of MNT_EXPIRE and traps - see below), etc., etc.

Areas where we still have to figure things out:

• MNT_EXPIRE handling done right; there are some fun ideas in that area, but they still need to be done in more details (basically, lazy expire - mount in a slave expiring into a trap that would clone a copy from master when stepped upon).
• traps and their sharing. What we want is an ability to use the master/slave mechanisms for *all* cross-namespace/cross-chroot issues in autofs, so that daemon would only need to work with the namespace of its own and no nothing about other instances.
• implementation ;-) It certainly looks reasonably easy to do; memory demands are linear by number of vfsmounts involved and locking appears to be solvable.
• whatever issues that might come up from MVFS demands (and AFS, and...)

There's a plan but no code yet. :)

linux-ide@vger.kernel.org is where this stuff gets discussed (though there's nothing on there recently about hotplug).

Here goes the third release candidate.

This one comes out to release a bunch of pending networking fixes from David Miller: netfilter, sctp, ipvs, etc.

Also changes the tty ldisc locking patches to not export a couple of API functions as GPL, because that breaks compatibility with older modutils.

This will become final if no problems appear.

Please help with testing!

IBM has announced that it will provide free access to about 500 of its existing software patents to users and groups working on open source software.

http://www.ibm.com/news/us/

Many of these patents relate to interoperability, communications, file-export protocols, and dynamic linking.

Past days I wrote about a regression test suite which i used to explain why a grsecurity-like security improvement could be good for mainline inclusion, and also, that at least the 50% of the faults it shows on Vanilla sources could be solved without major blocking issues (aka big deals, whatever else).

I've released the code, so, everybody could mess it up and send me patches with fixes, enhancements, extra features or better source comments ;)

The source code is available at http://cvs.tuxedo-es.org/cgi-bin/viewcvs.cgi/collision-rts/.

An example results log dumped by it when running on a default Vanilla kernel (no security patches, etc) can be found at: http://cvs.tuxedo-es.org/cgi-bin/viewcvs.cgi/collision-rts/results/vanilla-2.6-default.log?rev=1.1.1.1&view=log

In the forthcoming days i will try to add more tests to it, mainly related with capabilities and such, for SELinux and LSM testing. Also, maybe an ExecShield specific test (see [1] and [2]) and possibly a few other tests related with BSD Jails.

I would like to have feedback about it, but it's main goal is to show that there are still some security "faults" that affect users of Vanilla sources that can be solved without a lot of pain and could represent a start for those who want better security worked on many time before me and have been ignored or just left working alone and independently.

The suite has some tests related with "toolchain" hardening, but most stuff is kernel-related.

Here goes the fourth release candidate.

It reverts the root mount retry patch for USB/special devices, this is going to get fixed cleanly on v2.6.

And updates the i386 defconfig.

v2.4.29 announcement should follow shortly