Rusty's Remarkably Unreliable List of Pending 2.6 Features

I'm down to 8 undecided features: 6 removed and one I missed earlier.

	http://www.kernel.org/pub/linux/kernel/people/rusty/2.6-not-in-yet

(Reproduced below.)

Removed ("vendor-driven" == "no", for purposes of the freeze)
Linux Trace Toolkit: "no"
statfs64: noone seems to be pushing
ext2/3 ACLs & EA: included
Crash Dumper: "no"
Hi-res Timers: "no"
SCSI and FibreChannel Hotswap: "via. maintainers but probably not"

Added:
Nanosecond Time Patch

Linus, are you going to appoint [davej] someone [davej] to help you [davej] hold the freeze? It'd be nice if someone [davej] else had to pre-approve or co-approve patches before they went in.

I don't really care who the somebody [davej] is.
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Entrance criteria:

* Must have been submitted to lkml in the last month,
* Hasn't been rejected by the maintainer/Linus,
* Not appropriate for insertion during stable series (ie. too invasive, new feature, breaks userspace)

Key:
A: Author
M: lkml posting describing patch
D: Download URL
S: Size of patch, number of files altered (source/config), number of new files.
X: Impact summary (only parts of patch which alter existing source files, not config/make files)
T: Diffstat of whole patch
N: Random notes

In rough order of invasiveness (number of altered source files):
In-kernel Module Loader and Unified parameter support
A: Rusty Russell
D: http://www.kernel.org/pub/linux/kernel/people/rusty/patches/Module/
S: 841 kbytes, 290/48 files altered, 22 new
T: Diffstat
X: Summary patch (597k)
N: Requires new modutils

Nanosecond Time Patch
A: Andi Kleen
M: http://www.ussg.iu.edu/hypermail/linux/kernel/0210.3/0793.html
D: ftp://ftp.firstfloor.org/pub/ak/v2.5/nsec-2.5.44-2.bz2
S: 194 kbytes, 158/0 files altered, 0 new
T: Diffstat
X: Summary patch (181k)
N: The core of this patch is tiny: putting nanoseconds into filesystems is the bulk of this patch.

Fbdev Rewrite
A: James Simmons
M: http://www.uwsg.iu.edu/hypermail/linux/kernel/0111.3/1267.html
D: http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
S: 2320 kbytes, 131/20 files altered, 40 new
T: Diffstat
X: Summary patch (401k)

ucLinux Patch (MMU-less support)
A: Greg Ungerer
M: http://lwn.net/Articles/11016/
D: http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.45-uc1.patch.gz
S: 2202 kbytes, 25/13 files altered, 427 new
T: Diffstat
X: Summary patch (43k)
N: Linus said looks good.

POSIX Timer API
A: George Anzinger
M: http://marc.theaimsgroup.com/?l=linux-kernel&m=103553654329827&w=2
D: http://unc.dl.sourceforge.net/sourceforge/high-res-timers/hrtimers-posix-2.5.45-1.0.patch
S: 66 kbytes, 18/1 files altered, 4 new
T: Diffstat
X: Summary patch (21k)

Hotplug CPU Removal Support
A: Rusty Russell
D: http://www.kernel.org/pub/linux/kernel/people/rusty/patches/Hotcpu/hotcpu-cpudown.patch.gz
S: 32 kbytes, 16/0 files altered, 0 new
T: Diffstat
X: Summary patch (29k)

initramfs
A: Al Viro / Jeff Garzik
M: http://www.cs.helsinki.fi/linux/linux-kernel/2001-30/0110.html
D: ftp://ftp.math.psu.edu/pub/viro/N0-initramfs-C21
S: 16 kbytes, 5/1 files altered, 2 new
T: Diffstat
X: Summary patch (5k)
N: Linus says he wants it.

Kernel Probes
A: Vamsi Krishna S
M: lists.insecure.org/linux-kernel/2002/Aug/1299.html
D: http://www.kernel.org/pub/linux/kernel/people/rusty/patches/Misc/kprobes.patch.gz
S: 18 kbytes, 3/3 files altered, 4 new
T: Diffstat
X: Summary patch (5k)

I'm not sure exactly why this got a "no" this time around. For one thing, LTT is certainly not "vendor-driven", I'm not getting paid a penny for the work I'm putting in it ;)

In an earlier thread, Linus made the following statement with regards to LTT:

At that time we didn't have the per-CPU buffering, but I promissed Linus we would. And as promised we do have it now and the numbers we have published have clearly demonstrated the tracer is lightweight. So I was a bit suprised to see Linus come out and say:

Within that lengthy (ongoing) thread about "What's left over" he also mentioned a few criteria for admitting new patches:

I've answered this one a few times for LTT already. We don't want to live without this because we have no other way to:

Linus also added:

That's not really the case here. In fact, it's the complete inverse that is happening with LTT: Because I'm spending so much time having to deal with patch updates, I have much less time to work on the user-space analysis tools. These analysis tools are the heart of the tracing system and it is these tools that make LTT such a great utility, not the kernel patch itself. All the kernel patch does is act as a dumb data collector. It's the analysis tools that make sense of all this data and help the user pinpoint his problem.

To the question "did you convince anyone else of including LTT in their distro before trying the LKML?", my answer is: We didn't have to, they included it without asking. Within 2 days of releasing the first version of LTT in July 1999, I got an email from Zentropix (which would later be acquired by Lineo) that they were going to include it in their distro. At that time we only supported the i386 and the user tools were nowhere near what they are at today. Today, LTT is included by the following
distributions: MontaVista, Lineo, Debian, ELinos, Denx, and (to the best of my knowledge) UnitedLinux. Are we part of, say, RedHat? No we aren't, most folks I've spoken to have said that the LTT patch is far too big for them to maintain it independtly. I do, nevertheless, get many mails from users who ask: "Do you have an LTT patch for RedHat XYZ?" Obviously I don't, I simply can't generate an LTT patch for every distro out there.

"Why aren't any users of LTT being heard on the LKML?". Well they usually never have a problem with the kernel itself. I do, however, get tons of messages saying "do you have an LTT patch for version XYZ of the kernel?" or "patch version XYZ doesn't compile properly on architecture A." LTT users don't want to have to bother with the kernel, they want to get the trace data out of the kernel and into the visualizer in order to be able to debug their system. These guys aren't kernel developers, most of them are common application developers who need to identify serious problems having to do with the system's dynamic behavior. Which is exactly what LTT is about.

We do see, nevertheless, many folks come to the LKML and ask a question about being able to do a particular task with the Linux kernel and being told, by other people than myself, "take a look at LTT."

Over the past 3.5 years of working on LTT I've had the chance to discuss it with a few prominent kernel developers. I won't name any names, you know who you are. Many of those folks have shown interest in LTT. Even within the "what's left" thread folks came out and supported LTT's inclusion. I have yet to be explained why users _don't_ want to be able to debug their inter-process synchronization problems!?!

Can LTT continue to live outside of the kernel forever? Not without slowing down the development of the analysis tools significantly. Integrating the LTT patch into the kernel will certainly not mean the end of development of LTT because the LTT patch in and of itself is useless. The really interesting part is all in the user-space tools. That's what makes LTT a very important tool for users. The more time I have to put creating patch updates, the less time I have to actually work on the user-space tools.

Have a look for yourself (if you haven't already):
http://www.opersys.com/LTT/

And if you'd prefer something that speaks for itself:
http://www.opersys.com/LTT/screenshots.html

FWIW, please add this patch back. We've been very open to LKML feedback and have responded positively to the comments made by Ingo Molnar, Linus Torvalds, Roman Zippel, Christoph Hellwing, Pavel Machek, and many others. Either these people actually had lots of time to waste by going over our work and actually making suggestions, which is doubtfull. Either LTT is actually a tool that is worth taking an in-depth look at. I'll let you draw your own conclusions.

Meanwhile, we're all ears in regards to potential omissions and suggested changes.

Best regards,

Karim

===================================================
Karim Yaghmour
[email protected]
Embedded and Real-Time Linux Expert
===================================================

In message <[email protected]> you write:

"I don't know what this buys us" == "no" AFAICT.

You might surprise me, but it looks like Linus wants more trusted developers to come running to him going "LTT is really cool, we need it for XXX". Of *course* you think it's great, otherwise you wouldn't work on it.

You misunderstand. When Linus says "vendor-driven" he means what usually happens is that vendors pick it up then the users come back and convince Linus that it's worth including.

Hey, I feel your pain. Really: the module rewrite has the same issue, except I doubt a vendor would pick it up since it breaks compatibility with standard userspace, and they have enough to worry about.

I've put your patch back in, but I expect Linus will say "Rusty you fucking idiot, I already said "no" once."

Cheers,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Key:
A: Author
M: lkml posting describing patch
D: Download URL
S: Size of patch, number of files altered (source/config), number of new files.
X: Impact summary (only parts of patch which alter existing source files, not config/make files)
T: Diffstat of whole patch
N: Random notes

In rough order of invasiveness (number of altered source files):

In-kernel Module Loader and Unified parameter support
A: Rusty Russell
D: http://www.kernel.org/pub/linux/kernel/people/rusty/patches/Module/
S: 859 kbytes, 296/44 files altered, 24 new
T: Diffstat
X: Summary patch (609k)
N: Requires new modutils

Nanosecond Time Patch
A: Andi Kleen
M: http://www.ussg.iu.edu/hypermail/linux/kernel/0210.3/0793.html
D: ftp://ftp.firstfloor.org/pub/ak/v2.5/nsec-2.5.44-2.bz2
S: 194 kbytes, 158/0 files altered, 0 new
T: Diffstat
X: Summary patch (181k)
N: The core is tiny: putting nanoseconds into filesystems is the bulk of this patch.

Fbdev Rewrite
A: James Simmons
M: http://www.uwsg.iu.edu/hypermail/linux/kernel/0111.3/1267.html
D: http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
S: 2320 kbytes, 131/20 files altered, 40 new
T: Diffstat
X: Summary patch (401k)

Linux Trace Toolkit (LTT)
A: Karim Yaghmour
M: http://www.uwsg.iu.edu/hypermail/linux/kernel/0204.1/0832.html
M: http://marc.theaimsgroup.com/?l=linux-kernel&m=103491640202541&w=2
M: http://marc.theaimsgroup.com/?l=linux-kernel&m=103423004321305&w=2
M: http://marc.theaimsgroup.com/?l=linux-kernel&m=103247532007850&w=2
D: http://opersys.com/ftp/pub/LTT/ExtraPatches/patch-ltt-linux-2.5.45-vanilla-021030-2.2.bz2
S: 257 kbytes, 68/3 files altered, 9 new
T: Diffstat
X: Summary patch (92k)

statfs64
A: Peter Chubb
M: http://marc.theaimsgroup.com/?l=linux-kernel&m=103610918825614&w=2
D: http://marc.theaimsgroup.com/?l=linux-kernel&m=103610918825614&w=2
S: 48 kbytes, 53/0 files altered, 2 new
T: Diffstat
X: Summary patch (32k)

POSIX Timer API
A: George Anzinger
M: http://marc.theaimsgroup.com/?l=linux-kernel&m=103553654329827&w=2
D: http://unc.dl.sourceforge.net/sourceforge/high-res-timers/hrtimers-posix-2.5.45-1.0.patch
S: 66 kbytes, 18/1 files altered, 4 new
T: Diffstat
X: Summary patch (21k)

Hotplug CPU Removal Support
A: Rusty Russell
D: http://www.kernel.org/pub/linux/kernel/people/rusty/patches/Hotcpu/hotcpu-cpudown.patch.gz
S: 32 kbytes, 16/0 files altered, 0 new
T: Diffstat
X: Summary patch (29k)

initramfs
A: Al Viro / Jeff Garzik
M: http://www.cs.helsinki.fi/linux/linux-kernel/2001-30/0110.html
D: ftp://ftp.math.psu.edu/pub/viro/N0-initramfs-C21
S: 16 kbytes, 5/1 files altered, 2 new
T: Diffstat
X: Summary patch (5k)
N: Linus says he wants it.

Kernel Probes
A: Vamsi Krishna S
M: lists.insecure.org/linux-kernel/2002/Aug/1299.html
D: http://www.kernel.org/pub/linux/kernel/people/rusty/patches/Misc/kprobes.patch.gz
S: 18 kbytes, 3/3 files altered, 4 new
T: Diffstat
X: Summary patch (5k)

How about Olaf Dietsche's filesystem capabilities support? It has been posted a couple times to LK, yesterday even.

We've had capabilities for ages (2.2?) but no filesystem support.

OpenBSD is recently bragging about no longer having any SUID root binaries on the system.

With FS capabilities we (Linux) can have the same situation. Security is a hot topic, and anything the kernel can do make security better/easier seems worthy of consideration.

Dax Kelson

Unfortunately Alexander has spoken again:

http://marc.theaimsgroup.com/?l=linux-kernel&m=103498212701476&w=4

You might want to check out some of the other reviews, I don't think people gave it very high marks.

Cheers,
Nicholas

Well, this was his first histerical response. In the meantime, all his points have been addressed. I haven't heard of new objections, did you?

I must have missed these. Unless you call promoting extended attributes a review, of course.

Regards, Olaf.

I have several comments.

Where are the capabilities stored? In a file called .capability in the root of the filesystem? Why would that root be writable, my current Coda development tree has a read-only top-level directory in which different realms can be dynamically mounted (similar to autofs).

How would I remove a capability from a vulnerable binary on readonly media (i.e. cdrom), while still allowing other applications on the same disk to run with special caps.

Right now an administrator can simply search for all setuid binaries to check for possible 'unwanted priviledge elevations'. With the proposed capabilities seemingly ordinary applications could suddenly have special powers. Also when I explicitly drop capabilities secure a system, these fs-caps could very well reintroduce a capability that were not in the permitted set of any of the running processes.

It is probably better to remove than to add capabilities. As everyone knows a setuid app is 'dangerous' use this code to remove some of the power that normally is associated with setuid. I.e. when the setuid bit is set for a specific application don't change euid to root, but still give the power to bind to priviledged ports.

In the end I believe capabilities (like setuid) should be a local decision. Yes, I'm looking at this from the viewpoint of a distributed network filesystem that crosses administrative boundaries, and as such I don't always trust whatever is stored in a mounted volume.

Why not modify a program like sudo or super that can give capabilities to processes based on local rules and configuration... Ok there already is a programs that does something like this which is called 'whichcap'.

Another solution is to have a trusted daemon that is the only process in the system with the capability to grant capabilities to other proceses. Other processes can send a request to this daemon, which can consult local rules, double check md5 checksum or whatever paranoia is needed before it actually does a setcap.

Jan

On Fri, 1 Nov 2002, Jan Harkes wrote:
[snip]

You might want to look at the VMS model. The sysadmin creates a startup script that tells the kernel which files are to be granted "amplified privileges" when activated. There's a dab of kernel code to maintain and implement this list, but there's zero filesystem code involved because these are not metadata. The kernel holds each "installed" file open as long as it's installed, so there's NO way to replace a trusted file without admin. priv.s -- you have to uninstall the file before you can monkey with it, and there's a priv. which controls the ability to do that.

Mark H. Wood, Lead System Programmer   [email protected]
MS Windows *is* user-friendly, but only for certain values of "user".

Judging from the silence, I guess my mails take the direct route from inbox to /dev/null ;-). But never mind, since the patch is very small, it's easy for people to add fs capabilities themselves, if they're interested.

#define _LINUX_CAPABILITY_VERSION 0x19980330 says, it's at least four and a half years old.

I think, it's not time for bragging yet, until fs capabilities get quite a bit more testing.

Regards, Olaf.

In message <1036175565.2260.20.camel@mentor> you write:

Hmmm... cutting it pretty fine 8)

I'm not sure how much it buys us in real life, but that's not my decision.

Added,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

I don't understand this. What do you mean with that?

I'm not sure how much iptables buy us in real life, but that's not my decision either. There are people - at least me ;-) - who are convinced, that fs capabilities are another piece in the security puzzle.

Regards, Olaf.

Ugh. Personally, as I've said, I'm not convinced filesystem capabilities is worth it, providing the illusion of security --- and probably will make most systems more insecure because most system administrators won't be able to deal with fs capabilties competently.

HOWEVER, if we're going to do it, Olaf's patches is really not the way to do it. If we're going to do it at all, the right way to do it is via extended attributes. Using a sparse file to store capabilities indexed by inode numbers is a bad idea; it will break if the user uses resize2fs on an ext2/3 filesystem, for example.

- Ted

Like ACL? SCNR :-)

I still don't get it. How is this different from suid root. The worst I can imagine is an admin doing chcap all+eip, which is no different from doing a chown root; chmod u+s.

Dragging yet another one out of you. This is a pretty strong argument against my implementation. Any other hints?

Regards, Olaf.

With dumping capabilities before resize and restoring them afterwards, you can solve this. See:
<http://home.t-online.de/home/olaf.dietsche/linux/capability/dumpcaps.pl>

Regards, Olaf.

The probvlem is that most software does not know abaout capabilities. A simple example is libc which will not ignore LD_PRELOAD because it does not notice that there is a difference in effective and real capabilities of the proces.

Personally I think this is solvable, and we realy need a way to enable admins to use the least priveledge principle on their servers by removing suid root programs completely.

Greetings
Bernd

www.freefire.org

I see this as a "vendor, RPM maintainer, developer" thing. The developer,vendor,RPM mainter should be able to determine exactly what capabilities an otherwise SUID root app needs and ship it appropriately.

Most sysadmin can't 'deal with X', where X is:

- Setup routing properly
- Configure kerberos
- Compile a kernel
- Use setfactl
- ext2/3 attributes
- IPTables
- SGID directories
- Apply a patch

That doesn't mean we should remove the above because they can be used incorrectly/inappropriately and possibly damage and/or insecure a system.

Dax

Most don't need to. The lst time I did Kerberos I believe it was on a Sun-3. To special use and security issues you might add custom PAM. The other stuff on your list a good admin should be able to do, although more sites are using a "vendor kernel only" policy.

bill davidsen <[email protected]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Clearly inode numbers are a bad way to handle it, but I don't think inode attributes are that great either. I would personally prefer directory entry attributes, so that the same file can show up with different behaviour in different places.

I think it was a mistake to have permissions be part of the inode in the first place, but that's UNIX for you. A direntry-based approach is _so_ much more flexible, and doesn't really have any downsides.

(Having attributes in the direntry also makes it possible to much more efficiently scan directories for types of files without having to look up the inode information).

We can't fix the UNIX permission issue, but if we _do_ make FS capabilities available, I will personally cast a strong vote for not hiding the information in the inode.

There are two fairly trivial ways to do it:

- put the actual data in the directory entry itself. This is efficient, but not very easily extensible, since most directory structures have serious size limitations.

- Make a new file type, and put just that information in the directory (so that it shows up in d_type on a readdir()). Put the real data in the file, ie make it largely look like an "extended symlink".

The latter approach is probably a bit too reminiscent of a Windows "shortcut" aka LNK file to some people, but hey, maybe it's a good idea.

Linus

The main downside is the problem, that an object then can have multiple different permissions and there is no easy way to ensure a basic level:

a- the kernel can't drop priveledges on a modified object easyly (this would require your attribution to contain a version or checksumed reference) b- the user can't drop/restrict a object once he knows that it's data is now more sensitive (he has to worry about all old hard and softlinks to the file)
c- how do you handle renames or moves of the data instances? move the associated permissions of the moved entry and let all others point to nil like breakign symlinks?

Greetings
Bernd

reading directories therefore causes lots of seeks and performance begins to suck again

IMO, extended attributes are a better place to store this and making it per-inode, there is an argument that having a file behave differently in different places is unecessaryly complex and really doesn't solve any know real-world problems

--cw

I'm sure we can come up with even more confusing behaviour if we want, but it'll take some serious creativity.

Sure it's more flexible, but I wonder how many userland programs will be broken if we change the permission model and how well users can protect their data this way.

regards,

Rik

Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/		http://distro.conectiva.com/
Current spamtrap:  <a href=mailto:"[email protected]">[email protected]</a>

This is not a "change". Existing behaviour clearly cannot change. We're talking about new interfaces to export capabilities in the filesystem.

And pathnames are a _hell_ of a lot better and straightforward interface than inode numbers are. It's confusing when you change the permission on one path to notice that another path magically changed too.

Linus

It's equally confusing to find out that link(2) doesn't preserve file properties.

Frankly, I'm less than sure that ability to raise capabilities is a good thing - being able to drop them is certainly nice, but I doubt that partial suid-root will be better than full suid-root and it certainly makes security model even more complex. And incomplete understanding of security model is a great recipe for PITA - demonstrated way too many times already...

Folks, seriously - it might be very tempting to add features in that area, but more features actually increase overall security. Just look at the track record of systems with baroque security models and ask yourself whether we want to go there.

Arrgh. s/increase/decrease/, obviously

Hi!

I dont think its good idea to add capabilities this way: make fs capabilities drop only, and if you want to raise, make it setuid root.

Kernel will see its suid, will raise capabilities, and then drop them according to the fs fields.

Thats okay, and old apps will see its suid root and treat it with care.

The only bad thing about this is how to make something suid games, addcap hw access.

			PavelEnd_of_mail_magic_5574

It's also going to be confusing when you change permissions on an inode and the extended attributes in one of the paths to the inode don't change with it.

It'd be confusing as hell if I did a 'chmod go-r' on a file I own, but have others continue reading the file because of some extended attributes giving them the rights to do so.

Or am I misunderstanding the kinds of extended attributes you want to have determined by pathname instead of by inode ?

It'd be nice to have an overview of exactly which permissions and attributes are per file and which are per pathname ;)

regards,

Rik

Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/		http://distro.conectiva.com/
Current spamtrap:  <a href=mailto:"[email protected]">[email protected]</a>

Look at the subject line.

Linus

Would this not allow a user to add permissions to a file, by creating a new directory entry and linking it to an existing inode?

Would that not be a greater security hole?

No. The file itself has _no_ capabilities at all. If you just link to it, you can give it whatever capabilities _you_ have as a user (well, normal users don't really have any capabilities to give, but you get the idea).

Linus

So, this would be the inheritable set only.

Regards, Olaf.

Capabilties done right, means that normal users DO have capabilities. Normal users have the capability to call normal syscalls like "read", "write" and "execve".

And once you have these included in the capabilities (which normal users and programs normally have by default), you can take them away if you want. For example, a non-scripting webserver may not require any use of the "execve" system call.

Oh, it's easy to get a "vector" of over 100 capabilities this way. This might be inefficient. Thus, it would be required that we get two levels:
first level as you're thinking of it: split capabilities for what "root" now has, and the other also splitting the "normal user"'s capabilities (and splitting the root-kinds even further).

Roger.

** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* The Worlds Ecosystem is a stable system. Stable systems may experience *
* excursions from the stable situation. We are currently in such an      * 
* excursion: The stable situation does not include humans. ***************

This is IMHO very desireable, but not part of POSIX capabilties and also even more intrusive on the applications.

Even on Windows NT you do not have such User capabilties. With a good namespace and ACL concept, you can get around it, most of the time. (although a object based security is not always as good as a subject bound).

Greetings
Bernd

So you are talking about a new interface that sucks. Slight difference in situation no difference in result. At the point where link/rename and even NFS happenings on remote boxes may get involved I don't want to go anywhere near it. One thing Unix actually got right from the beginning is that rights belong to objects not to names. Name based labelling has never worked in or out of computing.

What you are suggesting is the equivalent of marking documents 'secret' by putting them in a specific drawer and hoping nobody ever misfiles it. Everyone instead writes "secret" on the document - guess why

I think the most important aspects are always that the concept is understandable, doesn't make the users to jump through hoops, and doesn't violate the principle of least surprise too often.

This happens if you have a design that is based on taking away privileges/rights/capabilities/power/whatever. If the "naked" object has no special powers, misfiling it does no damage at all.

Of course, you want to make sure nothing else can be slipped into that magic drawer. Just imagine somebody takes the GPL from The Drawer of World Domination, and puts the Windows EULA there :-)

- Werner

  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         [email protected] /
/_http://www.almesberger.net/____________________________________________/

That isnt actually true. When you misfile it you mistakenly give it powers. An untrusted document stuck in the secret drawer becomes seen to have much higher value. It might for example lead the military to believe a project is secret, make a decision on that basis and get everyone shot because the opponents knew about it.

Alan

How would you go from a regular file to the new extended symlink?

Regards, Olaf.

I don't understand the question.

Let's say that you have a binary like /usr/bin/sendmail, and you want to give it a certain set of capabilities (ie you want to _avoid_ making it suid root - you only want to give it the specific capability of being able to chown files to others and whatever else it is sendmail really wants to do).

So I'd suggest _not_ attaching that capability to the sendmail binary itself, or to any inode number of that binary. A binary is a binary is a binary - it's just the data. Instead, I'd attach the information to the directory entry, either directly (ie the directory entry really has an extra field that lists the capabilities) or indirectly (ie the directory entry is really just an "extended symlink" that contains not just the path to the binary, but also the capabilities associated with it).

The reason I like directory entries as opposed to inodes is that if you work this way, you can actually give different people _different_ capabilities for the same program. You don't need to have two different installs, you can have one install and two different links to it.

Linus

<shrug> that can be done without doing anything to filesystem.
Namely, turn current "nosuid" of vfsmount into a mask of capabilities. Then use bindings instead of links. *Note* - binary _is_ marked suid, mask tells which capabilities _not_ to gain. It's OK - attempt to link(2) to the thing using binding will see that oldname and newname are within different vfsmounts, so instead of link to suid-root binary you get -EXDEV.

And that works on any fs, can be made per-user and can be _seen_
by admin - bindings are visible in /proc/mounts (yes, I remember that we need to fix the crap with pathnames).

I can do that thing in a weekend - it's trivial to implement.
No need to bugger filesystems for that.

I like that idea. It's very explicit, and clearly name-based, and we do have 99% of the support for it already.

Linus

It occurs to me that we actually do have the "extended symlink" concept in UNIX already: the existing "#!" escape for executables is really exactly that. It's just a structured symlink, except the extension is not a capability, but rather it's the script to be fed to the executable.

With a simple extended binfmt_misc.c or binfmt_script.c, we could do a capability escape (that only removes capabilities, but allows for suid shells) fairly easily if people really want it. And it would work on any almost-UNIXy filesystem, including NFS etc.

But I like Al's idea of mount binds even more, although it requires maybe a bit more administration.

Linus

OK, will do - will be fun to take a break from drivers/* and devfs excrements I'm digging in...

BTW, here's a fresh demonstration (found half an hour ago) that capabilities do *not* permit more lax attitude when writing stuff with elevated priveleges:
* /usr/lib/games/nethack/recover is run at the boot time (as root)
to recover crashed games.
* Debian nethack 3.4.0-3.1 has it installed root.games and it
is group-writable - cretinism in debian/rules, upstream is not guilty in that (BTW, so is /usr/lib/games/nethack/recover-helper).
* ergo, any exploitable hole in sgid-games binary (rogue, for
instance) is trivially elevated to root exploit.

Capabilities will *not* help that one - suid-games binaries need
to be able to write as 'games', that's the whole reason why they are suid-games. Normally they use it to create save files. And quite a few of them are ripe with exploits - c.f. recent rogue(6) holes.

Normally that would lead only to ability to screw others' save
files (and potentially to compromise their accounts, if corrupted save file can trigger a hole in another game). Besides, many of these beasts are old and didn't get too much attention.

Now, combined with packaging fuckup (which is a nice prototype of
ACL fuckups to come) we get a lovely path leading to root exploit. Bugger all, one *still* has to think when writing code. A shame, isn't it?

This is why you also want something stronger than just capability models. In a strong security system the following happens.

User hacks nethack
Users compromises recover (and in doing so reduces its integrity)

Reboot
Root tries to run recover
Recover has insufficient integrity
Error messages appear

You would also have a "game playing" role which would mean a compromised game could only write to the game score and save files, and could only read the nominated game configuration files.

The problem with this is its nontrivial to set up all the rules. Being able to use namespaces to revoke rights is a big help. If we were to add a capability for 'getting out of chroot' then we can also combine it with chroot to drop users into an unpriviledged universe from which they cannot escape because we took away the chroot stuff and we took away rawio and so on

Alan

No messing with chroot needed - just a way to irrevertibly turn off the ability (for anybody) to do mounts/umounts in a given namespace and ability to clone that namespace. Then give them ramfs for root and bind whatever you need in there. No breaking out of that, since there is nothing below their root where they could break out to...

mkdir foo
chroot foo
cd ../../../..
chroot .

Alan

... will give him nothing, since he is not in chroot jail to start with. He has a namespace of his own with his own root filesystem. Which has several empty directories and nothing else - everything else is bound on these. He is at his absolute root and can't break out of it - there is nowhere to break out. So his /foo will be a subdirectory of root of his root filesystem. OK, he chroots there. His cwd is still at absolute root and he can follow .. until he's blue in the face - he will stay where he started.

Plan 9 !

---------------------------------------------------------
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
www.fsmlabs.com  www.rtlinux.com
1+ 505 838 9109

Well, yes. But also Linux. The code is all there, and you can create a new namespace group with just a simple CLONE_NEWNS. Then you just do pivot_root() in that namespace, unmount the old root, and you're done.

Yeah, yeah, I'm sure I forgot something, glossed over the details, and a real example is more involved. And I'm also sure it hasn't been used in practice all that much, but Al's point is that this is much more than "chroot()", and is actually safe from all the normal chroot problems. Because the namespace is not a part of the old tree - it's a completely new tree with no connections to the old one.

We got it pretty much for free (*) with the vfsmount stuff - which in turn was needed for bind-mounts.

Linus

(*) Although, to be honest, it's hard to say how much of it was "for free", and how much of it was the normal "Al thinking ahead a year or so while doing incremental patches". Al is scary that way.

So capabilities then just seems like a hack. You can write a trusted user space suid gateway program that consults a database, builds you a temporary file system with links and permissions to an otherwise hidden shared tree and puts you safely in that "temporary tree". If I understand what this does.

As for Al, he may be a great programmer, but it's his polemical writing style I appreciate most.

---------------------------------------------------------
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
www.fsmlabs.com  www.rtlinux.com
1+ 505 838 9109

That works for stuff where you are willing to live in a very limited environment.

Most people aren't willing to live in such environments. They want to look up user files in ~/.xxxxx, falling back to /usr/lib/xxxx/config, etc. And they want to take advantage of being able to use other programs in the system etc etc.

In other words, yes, you can create a temporary tree, and pretty much arbitrarily restrict what any process can actually see of the filesystem. But it's a _lot_ of work, and requires a lot of care, and by limiting your filesystem view you limit yourself to only using that view.

And the fact is, most programmers are lazy. They don't want to go to that effort, since it makes it harder for them. And you can't really blame them for that - especially since 99% of all projects evolve from something where security wasn't a big deal ("it's only for my own use anyway").

Look at how few programs bother with chroot(), and that's a lot easier to use (and portable).

Linus

PS. Yeah, to some degree namespaces are at least in theory easier to use than chroot, since they allow for a lot more flexibility and you can cherry-pick and do things like just re-mount /usr/bin with nosuid inside your namespace, which chroot doesn't allow. With chroot you end up having to copy the files explicitly and maintain a separate chroot directory structure.

I seem to remember Al talking about the namespace stuff around 2.4.<early>. Good to hear all the incremental pieces have made it in now ;)

Rik

Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/		http://distro.conectiva.com/
Current spamtrap:  <a href=mailto:"[email protected]">[email protected]</a>

A call from left field:

As a sys-admin I love the idea of the capabilities, but I hate this mount --bind thing. I'd really rather see it have its own command name. If it were strictly something that happens at mount time for a filesystem that'd be one thing, but

looks like a mistake.

If you were loop mounting the binary into the user's directory, then I could see using mount.

This would be clearer:

setcap -c xx,yy /usr/bin/foo

(I also have nothing against long option names.)

The end is a finish, a conclusion or a completion.
http://www.hacksaw.org -- http://www.privatecircus.com -- KB1FVD

[email protected] (Hacksaw) wrote on 03.11.02 in <[email protected]>:

As a sysadmin, this should be about 20 seconds with your favourite editor to create a "setcap" shell script.

MfG Kai

Ville Herva pointed out that it'd be modifying in core structures, so maybe it is the right thing to do. I do like the idea of every setuid file needing to be listed in one place.

I still find "mount --bind --capability=xx,yy /usr/bin/foo /usr/bin/foo" to be a strange syntax. It implies that one is mounting /usr/bin/foo over /usr/bin/foo, and adding the xx,yy capabilities.

What we hear is the way that we hear.
http://www.hacksaw.org -- http://www.privatecircus.com -- KB1FVD

Sun, 03 Nov 2002 05:50:24 -0500: Hacksaw (Hacksaw
<[email protected]>):

This could be an argument _for_ doing it this way. As a sysadmin myself, this makes a lot of sense to me, and being able to catch it by looking in a 'mount' command is certainly a sweet proposal-- That way you can constantly monitor anything that needs extra capabilities very simply.

And if mount supported an argument to ONLY show capability remounts, there's a quick 'showcap' for you.

< There is a light that shines on the frontier >
<   And maybe someday, We're gonna be there.   >
<    Rando Christensen / [email protected]    >

The two are seperate things IMHO

Namespaces is a way to inherit revocation of rights on a large scale (or a small one true). #! is a way to handle program specific revocation of rights which _is_ filesystem persistent.

The former is a database view, the latter is an actual database change

#! would be a nice option to increase capabilities on invocation. But the final target must be linked to the invocation by an entity/revision binding. Since we do not have modification versions i could think about checksums:

#!#/bin/setcap
10de6c9a339800777c2a8c43a7def924 /bin/ls
+NET_ADMINe

This even will add another integrity checking layer tp the system.

Greetings
Bernd

Unfortenately it will be much harder to find all executables with increased capabilities on your system.

Ragnar Kjørstad
Big Storage

Depends if you insert the capabilities/checksum into single files all over your file system or in a central /etc/capabilities.conf file. The later is a bit like other security linux distributions and has clearly the advantage of beeing more obvious.

The scheme could be extended for non capability related integrity checking. For exampel all root programs need to be listed there with checksums or someting like that.

Greetings
Bernd

You need a way to mark applications which may be run with increased capabilities and which ones are permitted yes, and by object not by name

I do not think having md5 sum of /bin/ls helps so much -- what if I moify ld.so, instead?
Pavel

When do you have heart between your knees?

the checksum is intended to mimic the exisiting priveledge revocatin on altering. You could of course all all depenendn modules as checksums too, but this would be more our current suid system supports.

Greetings
Bernd

Look at <http://marc.theaimsgroup.com/?l=linux-kernel&m=101639590421603>.

Regards, Olaf.

Bindings are cool, but once you start talking about doing a lot of them, they're rather ungainly due to not actually being persisted on the filesystem, no?

A better approach is to just make a user-space capabilities-wrapper that's setuid, drops capabilities quickly and safely and calls the real app. Something like:

# mv ping ping.real
# chmod -s ping.real
# mkcapwrap +net_raw ping.real
# chmod +s ping
# showcapwrap ping
invokes /bin/ping
grants net_raw
#

No fs magic, no persistence issues, all user-space.

 "Love the dolphins," she advised him. "Write by W.A.S.T.E.." 

Do you mean?

# mv ping ping.real
# chmod -s ping.real
# mkcapwrap +net_raw ping
# chmod +s ping
# showcapwrap ping
invokes /bin/ping.real
grants net_raw
#

The wrapper needs to setuid/gid to the uid/gid that invokes it.

uid root with no caps (or few caps) is still very powerful (replace binaries owned by root, read /etc/shadow, etc).

Currently all capabilities are cleared when non-root app does a execp. This would need to be addressed.

Dax

Actually I meant:

# mkcapwrap +net_raw ping.real ping

..in keeping with ln(1).

Generally, though there'd need to be an option to emulate, say, setgid mail.

Hrmm. I thought the inherit mask dealt with that.

 "Love the dolphins," she advised him. "Write by W.A.S.T.E.." 

Look at sucap and execcap available with libcap. Combine them and you get a capability wrapper.

You need the inherit set of the parent process _and_ the inherit set of the binary to agree. For the latter you need some sort of fs capabilities.

Regards, Olaf.

Well, they _are_ persistent in the filesystem, although in this case "the filesystem" is /etc/fstab.

It's not that different from the ".capabilities" file, except it's a lot more explicit, and from an implementation standpoint it's a lot easier.

However, I think there is a problem with Al's original approach: the bind can _not_ be just a mask that takes away capabilities from a suid application, since that would imply that the app has to be marked suid in the first place (and accessing it _without_ going through the bind will give it elevated privileges, which is what we're trying to avoid).

So the bind would have to _add_ capabilities, not take them away.

That's not really a problem, and the advantage of the filesystem bind approach is that it is extremely explicit, and it is trivial for a maintainer to at all times see all such "elevated" binaries: as Al points out, the only thing you need to do is to just ask to be shown the mount list with "mount" or with "cat /proc/mounts".

This is _not_ a good approach from a sysadmin standpoint. The sysadmin does not explicitly know what the suid binary does internally, the sysadmin just sees a number of suid binaries and has to trust them.

Yes, I realize that your example had "showcapwrap" etc sysadmin tools to work around this, and make the wrapping be transparent to the sysadmin. That certainly works, although it still depends on trusting that the wrapping cannot be confused some way. I guess that could be done fairly easily (although I think you'd want to make "mkcapwrap" actually _sign_ the wrapped binaries, to make sure that nobody can later try to inject a "bad" binary that _looks_ ok to "showcapwrap" and fools the admin to think everything is ok).

But from a security maintenance standpoint, wouldn't it be _nice_ to be able to

- do a complete "find" over the whole system to show that there is not a single suid binary anywhere.

- trivially show each and every binary that is allowed elevated permissions (and _which_ elevated permissions) by just doing a "mount".

- and since the mount trees are really per-process, you can allow certain process groups to have mounts that others don't have.

I think that as a anal-retentive security admin, I'd like such a system.

Linus

No, that's OK -

mount --bind /usr/bin/foo.real /usr/bin/foo.real
mount -o remount,nosuid /usr/bin/foo.real

or equivalent couple of mount(2) calls will do the trick nicely (and that, BTW, we have right now - you can selectively disable/enable suid on files and entire subtrees).

Ehh. With the nosuid mount that will remove the effectiveness of the suid bit (not just the user change - it will also mask off the elevation of the capabilities), so the bind-mount with the capability mask will now mask off nothing to start with.

Wouldn't it be much nicer to have:

/usr/bin/foo - no suid bits, no capabilities by default

  mount --bind --capability=xx,yy /usr/bin/foo /usr/bin/foo

where the mount actually adds capabilities? Looks more understandable to me.

Linus

Nope. Look - ->i_mode is still the same, nothing had changed. Suid interpretation happens *not* on a superblock level. What happens is
* we look at file->f_dentry->d_inode->i_mode. No suid bit - no love.
* then we look at file->f_vfsmnt->mnt_flags. If that has MNT_NOSUID -
no love, again.
* if suid bit is present and vfsmount is not marked nosuid - there
we go.

In other words, nosuid status is _already_ per-binding - having a nosuid binding at /usr/bin/foo.real doesn't have anything to do with suid (or partial suid) bindings elsewhere.

So trick above will remove effectiveness of the suid bit for binding at the place where real binary lives. If you want that place to retain some capabilities - s/nosuid/capmask=.../ in the above. It has nothing to do with other places where you might bind the same file - each binding has its own vfsmount and thus its own ->mnt_flags...

Ok, I get your example, but nope, I don't think it will work.

Why? Because then the suid check will work, and not only will you get all capabilities (_if_ the suid was root), you will also have changed your ID (since that was how you got enough capabilities to be able to mask them off).

Which you do _not_ want to do. You just want the capabilities, you don't necessarily want to run as somebody else (or if you do, that "somebody else" might well be "nobody"). So suid vs capabilities are different: you may even want them to be complementary.

In other words, it would actually make perfect sense to have

-r-sr-sr-x 1 nobody mail 451280 Apr 8 2002 /usr/bin/sendmail

  mount --bind --capability=chown,bindlow /usr/bin/sendmail /usr/bin/sendmail

ie have it be suid nobody:mail (to _remove_ any vestige of normal user rights but give it write permission on the mail directory), and then separately giving it specific capabilities to allow it to chown files it creates and bind to port 25).

(yeah, maybe that's a bad example, I dunno what sendmail actually wants to do).

In the above, the suid'ness of the binary is totally independent of the
capabilities: the suid bits don't have any meaning for the capability set, since it's not about root, but the suid bits _do_ have meaning from a filesystem permission standpoint.

Linus

Umm... As for getting all capabilities, I was planning to do the following:
modify suid check to give you everything except the mask taken from vfsmount. So that's no problem - this is exactly the place I would modify.

Now, _that_ may be more serious. However...

*blam*

Congratulations with potential crapload of security holes - now anyone who'd compromised a process running as nobody can chmod the damn thing and modify it.

And that is the reason why suid-nonroot is bad. It creates a class of binaries that can easily give you a root compromise if one of them has an exploit - even if that one is never run by root. That is the reason why such things are done with sgid-nonroot and not with suid. Member of group can't chmod. Owner can. And yes, you can take away chmod - but you need to do that for everything that will run with that UID. Which might be impossible - some might need chmod(2).

FWIW,

$ ls -l /usr/sbin/sendmail
-rwxr-sr-x    1 root     smmsp      617672 Oct  2 13:33 /usr/sbin/sendmail

- no suid at all. And making it suid-nobody would decrease security.

Note that _all_ binaries that need any capabilities now are written to be suid-root. So the only case left from your scenario is
* new binary
* runs with UID of caller
* wants some capabilities
* doesn't want to be portable (it won't work on any other Unix,
since we had assumed that it doesn't want to be suid-root and still relies on caps present)
* doesn't use any of $BIGNUM portable mechanisms (separate
helpers, descriptor-passing, yadda, yadda).

Umm... Do we really want to help these out? We don't even have an excuse of that being an important 3rd-party program brought from some other system - it will be Linux-only and new, at that.

Now, _removal_ of capabilities on exec makes a whole lot of sense - suid or not. So IMO correct way to look at the stuff that adds them as suid-root slighlty mitigated by removal of some things.

I can do addition of capabilities via the same mechanism - it's trivial. But I really doubt that we want it as first-class thing.

Comments?

Speaking of user 'nobody', modern best practices (and shipped vendor configuration) strongly discourages lumping everything under 'nobody'.

Each app should run in its own security context by itself. That is why I have all the following users in my /etc/passwd:

apache nscd squid xfs ident rpc pcap nfsnobody radvd gdm named ntp

I didn't have to do this myself, my vendor shipped it that way. I don't have any daemons running as 'nobody'.

I think it is well understood that having more than one app run as the same uid (historically, nobody) is a Bad Thing(tm).

Generally speaking yes, but don't remove that ability for those who have applications/circumstances where suid-noroot+caps can be a simple and clean solution. Vendors, of course, are not likely to ship suid-noroot+caps binaries.

Pardon if I miss parsed.

On a 'everything install RHL8.0', there exists 47 SUID root binaries.

Don't we want to convert them to 'run with UID of caller and with some capabilities'?

Isn't this the common case?

A process executing as root, even with ZERO capabilities, is still quite privileged/dangerous. That process can replace root owned binaries, and read /etc/shadow.

I see two problem spaces that capabilities helps with:

1. SUID root binaries --> run as caller with need capabilities
2. root daemons --> run as defined non-root user with capabilities

Problem space 2 can be tackled right now assuming the daemon doesn't try to fork+exec another binary and expect that binary to inherit the capabilities that it has.

See above :)

Yes, but there is more to that. Namely, these daemons acquire their UIDs not via suid bit and they are very likely owned by some other UID (root, most likely).

3. suid-root that needs full-caps (check and you'll see quite a few of these. just at random - sudo, chfn, mount). These are equivalent to root - either by function (if su can't give me root, I'll be _really_ PO'd) or by trivial elevation of priveleges available if they are subverted (are capable of changing the file that contains, among other things, shell of UID 0, are capable of calling mount(2), which is enough for everything).

4. can be modified in a way that wouldn't require suid or would _really_ require it for a small helper (i.e. there is a small piece that is root-equivalent, but it can be separated).

5. gratitious.

Care to give a splitup into these categories? And yes, (4) requires modification of programs - TANSTAAFL and all such...

As for (2) - most of those are started by priveleged process, so they need to drop capabilities more than acquire them. What exactly do you have in mind?

As a side issue each of these "users", or most of them, has likely also its own group and one needs also few groups for other purposes. Seems like the next potential point to bump into a numbers of groups barrier although probably most of these does not need to be shared. Still if this will become a part of a widely used security mechanisms there could be extra demands on memberships.

Michal

Well, wouldn't it be then logical to associate uids to capabilities, e.g. I could have ping binary setuid to user ping which would have just the necessary capabilities to operate?

Antti Salmela

Welcome to accessfs :-)

<http://groups.google.com/groups?selm=87k7km9fti.fsf%40goat.bogus.local>
<http://groups.google.com/groups?selm=87elau9ft2.fsf%40goat.bogus.local>
<http://groups.google.com/groups?selm=878z129fnz.fsf%40goat.bogus.local>

It's not exactly what you asked for, but I think it's the closest you can get at the moment.

Regards, Olaf.

This is solved by some implementations of POSIX capabilities by zapping any capabilities if the executible is modified --- just as some Unix systems zap the setuid bit if the executable is modified. It addresses specifically the problem that you've raised.

- Ted

Only until the file the path name is connected to is replaced. Then the trojan suddenly gains the capabilities of the real "foo".

Been there done that. That was one of the first security vulnerabilities in the VMS implementation of ACLs.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]

Any opinions expressed are solely my own.

Yes, but this has annoying side effects like booting single-user and discovering things like /sbin/ping doesn't exist because mount -a didn't run yet. Stuff like that sucks.

But they show up as regular files to things like ls. And magically break when copied, moved, etc.. Backups and bind mounts? It's not obvious to me how that works.

It's not perfect. Perhaps there's some #! script-like way to do it where there's only one binary to trust. One more point in its favor is it works in 2.4...

That's just show.

That might not strike _you_ as weird, but then this is the same guy who wanted files you could cd into..

You can do that with any capability scheme.

 "Love the dolphins," she advised him. "Write by W.A.S.T.E.." 

No. Because in single user mode, you are root.

Dax

No, /sbin/ping _would_ exist, it just wouldn't have gotten the elevated capabilities yet.

But that shouldn't matter in single-user mode, since it doesn't _need_ any elevated capabilities (unless you've somehow made your single-user mode run as a normal user - that's really secure, but you can't do anything with it ;)

[ In general the schenario you bring up is actually a good thing: a
failure mode would fail with _less_ provileges rather than more. Which on the whole is exactly what you want - failure to initialize something should not leave nasty security holes around. ]

On the other hand, I have this suspicion that the most secure setup is one that the sysadmin is _used_ to, and knows all the pitfalls of. Which obviously is a big argument for just maintaining the status quo with suid binaries.

We have decades of knowledge on how to minimize the negative impact of suid (I've used sendmail as an example of a suid program, and yet last I looked sendmail was actually pretty careful about dropping all unnecessary privileges very early on).

And as Al points out, new security features don't mean that you can just stop being careful.

Linus

Quite so. Now, ability to _remove_ capabilities on exec() is a Good Thing(tm) regardless of suid. It can be combined with suid - that gives you something that is still evil, but less than it used to be. But I don't see any point in new independent mechanism for raising caps - e.g. since it assumes a bunch of new programs that were written to run with elevated caps and with assumption that they will be less dangerous than suid-root ones. Somehow, it doesn't make me happy about running such programs - not for first 5 years or so.

Removing capabilities is an easy thing to add. Firstly the binary can do it anyway even on 2.4, secondly you can add an ELF property easily enough which says which capabilities this gets if it is marked setuid

As is shown every now and then, when the next security hole is reported. So we stay at the lowest common denominator.

I've always had good experience with educating people, not with dumbing them down. But maybe I've been just lucky then and worked with very smart people.

So we throw out the baby with the bath water. This is conservatism at it's worst.

Stating the obvious. Capabilities are not an end in itself, nor is suid root. It's just another line of defense to help with these binaries, which are _not_ capability aware.

Regards, Olaf.

Bullshit. To _be_ careful you need to understand the implications of what you are doing. To do so in a more complicated model is harder, not easier.

See Linus' suggestion regarding sendmail upthread - thing that looked like improvement of security (hey, we can make it never retain any traces of original UID, that should be good) had actually made thing more vulnerable.

More features != better security. Quite often it's exact opposite. Human do make errors, otherwise suid-root stuff wouldn't be a problem to start with. And when security mechanism increases probability of error it becomes a menace.

Odds of getting screwed are 0 if programs contain no bugs. We are dealing with real world and there are non-zero odds of exploitable holes being there and getting found. What we want is to decrease the odds of compromise, right? So how are ACLs/capabilities/etc. settings different from program internals? Either can contain bugs. Neither is guaranteed to be done correctly. Odds of compromise depend on odds of bugs in both. Yet you seem to imply that metadata *will* be set correctly. By the same vendors that had shipped vulnerable binary in the first place. Even though the complexity of metadata had grown.

Please, get real. "Completely understood" is much more important than "versatile" when it comes to security models. And as for additional lines of defense... How did it go? "For extra privacy that message had been twice encrypted with ROT13"...

Where did I, or anyone else, state the opposite?

Because it's harder for you to do a proper job, doesn't mean it is for everybody else.

Capabilities are not about adding features, they are about reducing. Face it, you just don't get it.

Agreed in _every_ _single_ _point_. But because there might be stupid vendors out there, doesn't mean I have to bow down to their level. And that is, what this is all about. I want to have this choice and fortunately, I have it.

So, what's your point? Like with suid root, capability settings need to be debugged, bug reports filed and people educated.

Well, _that_ is bullshit.

Regards, Olaf.

Huh?

Face it, you either just can't read or are deliberately being obtuse. New mechanism for raising capabilities doesn't have to be about adding features, IT IS A NEW FEATURE ITSELF.

Now, fuck off. To .procmailrc you go...

Thats a hard problem. Since your scan is non atomic and because you have directory notifications a running processes can have the setuid apps can move the setuid bits around the file system to hide from you.

Being able to give process trees a file system view which has certain capability raising properties removed is basically the existing capability mechanism but with a cleaner interface and more powerful semantics.

Doing that with just mount properties and using them to revoke rights works for me. There is a vfs corner case (clearly the setuid bit of a file that isnt setuid from this namespace point of view) which is very very important but not hard to get right.

I'm fairly certain that Linus was imagining a pre-compromise vulnerability assessment scan, not a post-compromise "figure out where the new holes are" scan, honestly. (You don't even need to have directory notifications, if you've got a process that is tormenting you like that, find can just be setup to not report certain things, etc etc.)

Ryan Anderson
  sometimes Pug Majere

The principle of least privilege says that instead of a system full of binaries running as root, we should have a system of binaries running as non-root with only the capabilities they need.

The typical break-in involves gaining non-root access first, then doing a privilege escalation attack to gain root. A system using capabilities makes the escalation attack must more difficult.

How are we currently doing? The following (pathetically short list of) binaries use capabilities:

vsftpd
ntptimeset
ntpdate
ntpd
named

What are the potential users of capabilities?

47 SUID root binaries (EVERYTHING install of Red Hat Linux 8.0)

Filesystem capabilities support could take care of these SUID root binaries. Historically, SUID root binaries have been heavily used in privilege escalation attacks.

How about daemons that are launched as root? These could be potential users of capabilities + drop root right now.

There is a snag though. When non-root binaries (eg, daemons running as non-root but with capabilities) execve(), all capabilities are cleared, so if some of these daemons need to exec other binaries with certain capabilities, it currently won't work.

"ps aux | grep root" to take a look. We see stuff like:

syslogd
cardmgr
apmd
smartd
xinetd
dhclient
gpm
crond
cupsd
anacron
rhnsd
login
mingetty
X

This is not an exhaustive list. The system I checked was not running many daemons.

In summary, there is lots that could be done today to secure daemons. The clearing of capabilities on exec by non-root binaries needs be addressed (I posted a patch in May 2002). File system capabilities support can fix the large amount of SUID root binaries that exist. OpenBSD 3.2 (just released) has started to implement a similar technique to get rid of SUID root binaries.

Once filesystem capabilities is added to the kernel, RPM and DPKG should be fixed so that, otherwise SUID root binaries, can be installed with capabilities support automatically.

This should be the vendors / package maintainers job. The average sysadmin should get the benefits without having to think about it.

Dax Kelson

Thanks for pointing this out. Most people seem to forget or ignore this.

Regards, Olaf.

I agree that package managers should eventually be made aware of capabilities, like they are now aware of file modes/ownership. There are several other configuration issues to figure out that may depend on the overall purpose of a system, like which user(s) are granted which capabilities when logging in, checking the capabilities of installed binaries, etc.

Yes.

--Andreas.

Any thoughts on how /usr/bin/(rpm|dpkg) copes with setting up the binding when installing a package?

Dax

<shrug> for example, /etc/init.d/foo-bindings.sh and update-rc.d invoked in post-install. Hell knows what RPM equivalent is, but there definitely is one...

postint script

-Erik

--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Sure, but editing /etc/fstab from postint is messy, potentially dangerous, and could possibly collide with someone doing a manual edit of /etc/fstab.

Maybe we need a /etc/fstab.d/ directory and teach /bin/mount about it.

Or have an /etc/fstab.d/ directory plus have an update-fstab script that collates the entries in that directory and stuffs the result into /etc/fstab, and have update-fstab called from the postint script.

-Erik

--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

I would forget about the update-fstab script. Why merge?

There is lots of precedent for the .d/ directories in /etc. These directories are mostly for the benefit of packages, and they have no update-foo scripts.

/etc/crontab & /etc/cron.(hourly|daily|weekly|monthly)/ & /etc/cron.d/ /etc/logrotate.conf & /etc/logrotate.d/
/etc/profile & /etc/profile.d/
/etc/httpd/conf/httpd.conf & /etc/httpd/conf.d/ /etc/xinetd.conf & /etc/xinetd.d/
/etc/lvmtab & /etc/lvmtab.d/
/etc/makedev.d/
/etc/pam.d/

Or
/usr/lib/menu/ && update-menus
/etc/modutils/ && update-modules
And there are tons of more, like generating mta-config from m4.

Anders Gustafsson - [email protected] - http://0x63.nu/

the suid bit is important, I agree. this will make most security checks not fail. Problem: runtime checks depend on euid. PErhaps we should even return a different effective uid (or 0?) if a program is runnign with increased capabilities?

Greetings
Bernd

So what are the semantics for writing to the file. If I modify a setuid (or setpartlysetuid) type file then I wan't the setuidness revoked as happens now. That is done for very good reason. Your system appears to need a scan of the entire file system to find directory references to this object, done atomically.

I'll trade 500K of disk space for a working security model especially as the case in question is not that common.

Alan

Here's a random idea, it has problems, but seems workable to me:

1) Add a standardized exported data structure to your ELF executable called "KERNEL_PROCESS_CAPABILITIES_v1" or another name you like, and have it as a fixed-length bit-array (null terminated) of capabilities, maybe 128 bits for version one. If extensions are needed later, we can fairly easily extend the length by aliasing it with another name, say "KERNEL_PROCESS_CAPABILITIES_v2" and sticking the extra bits at the end of the structure (or create a second structure...).

2) SUID root the binary like normal

This is what the kernel does:

1) Checks if the binary is SUID root (uid 0), if not go on like normal.

2) If SUID root, and it's an ELF execuable, look for the ELF symbol(s) above; if not present, set uid to 0 and execute.

3) If caps are present, read them in, don't change UID/GID, set the caps, and execute.

4) If that process executes another process, drop all capabilities

This could (probably be) extended to a.out format. To deal with scripts and 'binfmt_misc' stuff, you can create a capability called "CAP_WRAPPER" which allows capabilities to be transferred to the next process. When you execute that process, the kernel drops only that one flag, denying the wrapped executable from transferring capabilities.

Here's some advantages:
- No huge and wierd /etc/fstab[.d], and no mounting of files to gain capabilites, or other 'strange things'.
- If the kernel doesn't recognize capabilites, it'll just SUID root the binary like normal
- If the binary doesn't have capabilities listed, it'll just get SUID root like normal
- Changing the binary still drops SUID root, and thus drops the capabilites
- User can create wrapper 'binaries' fairly simply
- Since the size of the bitfield for the capabilities is fixed, the user can modify capabilites inside a binary with that structure.

Problems:
- It's binary, not text, so possibly harder to read without tools.
- Stripped binaries. This could be fixed by a small change:

Instead of using a symbol to look up capabilites, use text in the executable eg:

struct caps_t {
	int magic;
	char name[28];
	char caps[8];
} kern_proc_caps =
	{0x1234AA55, "KERNEL_PROCESS_CAPSTRING_v1", ... };

Comments?

Pat
--
Purdue Universtiy ITAP/RCS
Information Technology at Purdue
Research Computing and Storage
http://www-rcd.cc.purdue.edu

http://dilbert.com/comics/dilbert/archive/images/dilbert2040637020924.gif

I see no one has responded to this yet, so I'll ask again.

Does anyone have any comments about my idea outlined below?

Pat
--
Purdue Universtiy ITAP/RCS
Information Technology at Purdue
Research Computing and Storage
http://www-rcd.cc.purdue.edu

http://dilbert.com/comics/dilbert/archive/images/dilbert2040637020924.gif

[... capabilities in elf executables ...]

Take a look at <http://atrey.karlin.mff.cuni.cz/~pavel/elfcap.html>.
Maybe this is what you had in mind?

Regards, Olaf.

Similar, but not exactly the same:

1) Capabilities should be enabled explicitly not dropped explicitly - it's a 'more secure' way to do it.

2) Capabilities shouldn't be preserved across an execve except for once, as needed by wrapper scripts/binaries. This way even if someone figures out how to exploit the code to do an exec, they're left with no caps at all. If desired, a new binfmt "cap_wrap" could be created that can be used as a capabilities wrapper for executables, which the kernel looks at to determine 1) what caps to use and 2) what binary to run. The wrapper will need to be suid root in order to gain caps still.

3) Defining a new ELF header seems to me like it could (potentially) break backward/forward compatibility. My method preserves compatibility, with the only difference being if the app really gets capabilities or if it gets SUID root instead. If this really isn't a problem, you can take the works 'ELF Symbol' and change them to 'ELF Header' and make the idea still work the same in other aspects.

4) If the app has capabilities associated with it, no userspace code is run as uid 0, the kernel can avoid even changing uid during the execve syscall. It's just treated as a caps flag unless the kernel determines that the file has no capabilities, and then can run it as suid root.

Pat
--
Purdue Universtiy ITAP/RCS
Information Technology at Purdue
Research Computing and Storage
http://www-rcd.cc.purdue.edu

http://dilbert.com/comics/dilbert/archive/images/dilbert2040637020924.gif

For this you need to clear the permitted and inheritable set.

Here you will find capabilities with a new binfmt type:
<http://groups.google.com/groups?selm=linux.kernel.20020317121118.A18548%40glacier.arctrix.com>

Elfcap and capwrap both allow to have capabilities.

Regards, Olaf.

Now I understand. It's a combined symlink/capabilities pair. I thought to have this extra direntry, containing capabilities only. But I didn't get the connection between the binary and the cap direntry. You go just the other way round from cap/symlink to the binary.

I thought that's what the inheritable vs. permitted set is for.

Regards, Olaf.

If you modify the object you need to find all attached labels to downgrade it's capabilities. Therefore you need to find a way from the object to the capabilities stored in various entries.

Greetings
Bernd

For several years, I have had only one suid root binary on my system. All other 'setuid' applications are simply symlinks to this binary.

$ ls -l /bin/ping*
lrwxrwxrwx    1 root     root           14 Nov 18  2001 /bin/ping -> /usr/bin/super
-rwxr-xr-x    1 root     root        15244 Nov 18  2001 /bin/ping.suid

There is a a nice configuration file that is used to decide whether to use suid or setgid, which parts of the environment to drop/keep. And all of this based on the user, the time and any other conditions I would like to enforce.

Now super does not (yet) support capabilities. But it shouldn't be too hard to modify it so that it forks, drops capabilities, (possibly change the euid to the original user?) and exec the actual binary.

Jan

This sounds like the right way to go. I do hope the configuration file includes an SHA checksum of the secutable. And to avoid race conditions, there really ought to be a new system call, fexecve(2) which takes an open file descriptor instead of a pathname. (Unfortunately, we're in feature freeze now, so that will have to wait until 2.7.)

Failing that, though, /usr/bin/super should really check the permissions starting from the root of the entire pathaname, and fail the exec if any of the containing directories are writable by a non-root user. (And of course, the executable should not be writable by a non-root users for the same reason.)

With these checks, though, adding support for capabilities in /usr/bin/super sounds like the right approach. It doesn't require any kernel changes (well, fexecve(2) would be nice, but it's not strictly required). There is of course a slight performance penalty associated with the use of the helper program, but the start time of most setuid root programs probably isn't a performance critical concern.

- Ted

execve /proc/self/fd/n ???

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Inspired by this and because Alan of course cannot be wrong about something as simple as this I went on and implemented it. Just to jind that it's not working properly. Try this:

$ echo -e "#! /bin/sh\necho u1" > u1
$ chmod +x u1
$ echo -e "#! /bin/sh\necho u2" > u2
$ chmod +x u2
$ cat u.c
int
main()
{
  system ("cp -f u1 uu");
  int fd = open ("./uu", 0);
  char buf[100];
  sprintf (buf, "/proc/self/fd/%d", fd);
  char buf2[100];
  int n = readlink (buf, buf2, sizeof (buf2));
  buf2[n] = '\0';
  system ("cp -f u2 uu");
  execl (buf, buf2, "hallo", 0);
  return 0;
}
$ gcc -c o u u.c
$ ./u

You should see 'u2' as the result. But this is exactly what the fexecve call is supposed to prevent. The file, once opened, should be reused. The expected result is 'u1'.

The problem is, as you can see from the readlink call in strace's output, that /proc/self/fd/XXX is used as a symlink in the execve call.
The symlink of course refers to 'u2'.

And thinking back, I did try to write fexecve like this back when...

Anyway, any solution to this is welcome since the missing fexecve is regularly asked for.

- --
- --------------. ,-. 444 Castro Street
Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA
Red Hat --' drepper at redhat.com ---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9xtor2ijCOnn/RHQRAgHQAJ9YsYVnX9rKVYf9Rzy4fgUx5195pgCghnXC b5ZIJ1+vivZ2pWTmLxdrXtc=
=vJwO
-----END PGP SIGNATURE-----

No, you're wrong.

Your "cp -f" will _overwrite_ the already existing "uu" file. So the "cp" is actually overwriting the old binary, and it prints out "u2" as a
result: which is exactly the expected behaviour of "fexecve()". If you change the file itself, there's no way to execve() the old contents, because the old contents simply do not exist. That's true of fexecve() too.

To show what you want to show, you need to use "cp -fb" or something else that actually _switches_ the file around from under you. Or make the system() call do a "rm uu; cp uX uu". And if you do that, then you will see "u1". Try it and see.

In other words, "execve(/proc/self/fd/xxx)" does work and is exactly the same as fexecve().

Linus

So how would hard links be handled? Ignore the capability specified for the file?

That was a conscious decision to ensure that the ownership, and mode bits remained associated with a file no matter how the file is accessed (full path, relative path, hard link, or inode number). It also meant that there was only one place that might need to be updated if the permissions were changed. If they were in directories then all directories containing a link to the file would have to be updated (assuming you could find them efficiently).

Since all accesses HAD to go through the inode, it forced the security information to be united with the file, and could not be misplaced.

True, but a hard link would bypass whatever capabilities were assigned to the file. Also, what happens on things like mv or cp. Since mv only puts a name in the target directory with the inode number it would appear that any capabilities assigned to the file would be lost. Although cp should loose the capabilities, I would expect mv to preserve them.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]

Any opinions expressed are solely my own.

I think the arguments against having different capabilities for the same executable by different names have been made. It does seem that this would mean a symbolic link to the enabled directory entry would work and have capabilities, while a hard link to the inode would not?

Being hard to understand is one source of security errors of the "I didn't mean to do that" type.

I thought about symlink-like thngs when I was trying to envision an ACL by group, allowing control of a group other than the non-owner group to have more (or fewer) rights.

The problem with any form of link by name is that there's no easy way to tell from the inode how many pointers there are, and from the link to tell when the link target has changed. I could envision security attacks based on changing the base file and having capabilities apply via the link.

None of this is beyond implementation, but the idea of having something on a file inode certainly removes all attacks taking advantage of the link relationship. The best way to make something secure is to eliminate the need for it.

bill davidsen <[email protected]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Not to mention what happens if a file gets lost - fsck puts it in the lost+found directory, but without the protection specified by the owner.

absolutely

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]

Any opinions expressed are solely my own.

We have little experience with full blown capability enabled systems. Rushing things doesn't seem like a good idea. IMO we should wait until vendors have integrated FS caps before adding this to the standard kernel.

--Andreas.

And it will stay that way, if we don't start now.

Fact is, we have a capability enabled system for quite some time. It's just not making any progress regarding fs caps. But I must admit, that it may not be the time to include them into the mainstream kernel. On the other hand, if there were an implementation from someone Linus trusts, I'm sure he won't hesitate to include it right away.

BTW, it's really amazing how many people argue _against_ and how few are working _for_ fs capabilities. And it's not that anybody has shown real arguments against. Mostly uneasy fealings, eventual scenarios and bashing of stupid vendors and foolish sysadmins. This might score some points here and there, but it is not really helpful.

Anyway, have a nice time waiting. ;-)

Regards, Olaf.

Filesystem capabilities implemented, installed and running right now.

This was my point. After this discussion I am sure the patch won't be merged for 2.6 anyway.

[...]

Several pros and cons were brought up. In the end all that counts is whether the pros are big enough to warrant the cons.

--Andreas.