ubuntu kernel removes CAP_SETPCAP

care to comment?

Hi Jos,

You reported this bug a while ago and there hasn't been any activity in it recently. It appears this is still an issue. I will retarget this report to the upcoming Hardy kernel and have tagged it as 'hardy-kernel-candidate'. However, against linux-source-2.6.20 this bug does not meet the criteria for a stable release update and is being marked as Won't Fix. You can learn more about the stable release update process at https://wiki.ubuntu.com/StableReleaseUpdates . Thanks!

Cool! This allows more granular permissions for users. I'll test it out when the new hardy kernel comes out.

$ uname -r
2.6.24-2-generic
0 martin@donald:~$ sudo getpcaps 1
Capabilities for `1': =ep cap_setpcap-e

This is exactly how it should be. Allowing CAP_SETPCAP is crackful security-wise, since it allows root processes to randomly increase the privileges of other processes (violating a golden rule of security). Thus you potentially lose the enforcing of privilege restrictions.

I don't understand this explanation. With CAP_SETPCAP, I can give a process only priviliges to e.g. bind a low port, instead of full root privileges. How is this a bad thing?

Martin - per your opinion I've disabled CONFIG_SECURITY_FILE_CAPABILITIES which removes CAP_SETPCAP from the initial capabilities mask.

This bug was fixed in the package linux - 2.6.24-4.6

---------------
linux (2.6.24-4.6) hardy; urgency=low

  [Alessio Igor Bogani]

  * Fix -rt build FTBS.

  [Amit Kucheria]

  * LPIACOMPAT: Update thermal patches to be inline with lpia flavour
  * Poulsbo: Add USB Controller patch and corresponding config change

  [Fabio M. Di Nitto]

  * Enable aoe and nbd modules on hppa Ignore: yes
  * Fix ia64 build by using gcc-4.1

  [Tim Gardner]

  * Enable JFFS2 LZO compression.
    - LP: #178343
  * Remove IS_G33 special handling.
    - LP: #174367
  * Enabled CONFIG_SECURITY_CAPABILITIES and
    CONFIG_SECURITY_FILE_CAPABILITIES
    - LP: #95089
  * Enabled CONFIG_TASKSTATS and CONFIG_TASK_IO_ACCOUNTING
  * Turned CONFIG_SECURITY_FILE_CAPABILITIES back off.
  * Enabled CONFIG_B43LEGACY=m
  * Enabled CONFIG_SCSI_QLOGIC_1280=m
  * Enabled CONFIG_FUSION=y for virtual
  * USB bluetooth device 0x0e5e:0x6622 floods errors to syslog
    - LP: #152689
  * Removed lpia from d-i.
  * Added ia64 modules.
  * Added hppa32/64 modules.

  [Upstream Kernel Changes]

  * DMI autoload dcdbas on all Dell systems.
  * sched: fix gcc warnings
  * leds: Fix leds_list_lock locking issues
  * leds: Fix locomo LED driver oops
  * x86: fix asm-x86/byteorder.h for userspace export
  * x86: fix asm-x86/msr.h for user-space export
  * fix lguest rmmod "bad pgd"
  * slub: provide /proc/slabinfo
  * [POWERPC] Fix build failure on Cell when CONFIG_SPU_FS=y
  * slub: register slabinfo to procfs
  * [SCSI] scsi_sysfs: restore prep_fn when ULD is removed
  * Unify /proc/slabinfo configuration
  * scsi: revert "[SCSI] Get rid of scsi_cmnd->done"
  * restrict reading from /proc/<pid>/maps to those who share ->mm or can
    ptrace pid
  * Fix kernel/ptrace.c compile problem (missing "may_attach()")
  * hwmon: (w83627ehf) Be more careful when changing VID input level
  * NFS: Fix a possible Oops in fs/nfs/super.c
  * NFSv4: Fix circular locking dependency in nfs4_kill_renewd
  * NFS: add newline to kernel warning message in auth_gss code
  * NFSv4: nfs4_open_confirm must not set the open_owner as confirmed on
    error
  * NFSv4: Fix open_to_lock_owner sequenceid allocation...
  * IB/srp: Fix list corruption/oops on module reload
  * Console is utf-8 by default
  * [IA64] Update Altix BTE error return status patch
  * [IA64] Update Altix nofault code
  * [X25]: Add missing x25_neigh_put
  * [XFRM]: Do not define km_migrate() if !CONFIG_XFRM_MIGRATE
  * [CASSINI]: Fix endianness bug.
  * [CASSINI]: Revert 'dont touch page_count'.
  * [CASSINI]: Program parent Intel31154 bridge when necessary.
  * [CASSINI]: Set skb->truesize properly on receive packets.
  * [CASSINI]: Fix two obvious NAPI bugs.
  * [CASSINI]: Bump driver version and release date.
  * [INET]: Fix netdev renaming and inet address labels
  * [CONNECTOR]: Return proper error code in cn_call_callback()
  * [ISDN] i4l: 'NO CARRIER' message lost after ldisc flush
  * [ISDN]: i4l: Fix DLE handling for i4l-audio
  * fix: using joysticks in 32 bit applications on 64 bit systems
  * hda_intel suspend latency: shorten codec read
  * CPU hotplug: fix cpu_is_offline() on !CONFIG_HOTPLUG_CPU
  * Linux 2.6.24-rc7
  * PIE executabl...

Either I missed some discussion or there is some misinformation here.

CAP_SETPCAP is dangerous when CONFIG_SECURITY_FILE_CAPABILITIES=n because then it allows a task to grant capabilities to other tasks. So when CONFIG_SECURITY_FILE_CAPABILITIES=n, then CAP_SETPCAP is taken away at boot. Note however that init can reinsert it into the bounding set using /proc/sys/kernel/cap-bound. Only init can do it.

CAP_SETPCAP is safe when CONFIG_SECURITY_FILE_CAPABILITIES=y, because all it then allows is adding capabilities to the inheritable set (if they are in the bounding set). From there, it (or a child) needs to execute a file with the same bits in the file inheritable set in order to be able to get them into the permitted set. In other words, it's a way for login to grant capabilities to login sessions.

I'd like to see CONFIG_SECURITY_FILE_CAPABILITIES enabled so I can start using them on my ubuntu laptop, like I used to on my old laptop.

This bug is duplicated in Bug #232351, and in a Brainstorm entry:
 * http://brainstorm.ubuntu.com/idea/8104/

There seems to be some community interested in POSIX File Capabilities Support, and some mis-information about enabling/disabling it. It would be nice if we could clean this up for Intrepid.

:-Dustin

Changed the bug status to New because actually the opposite to what is needed was achieved (based on some misunderstanding).

Okay, I'm trying to summarize this:
 - _without_ the CONFIG_SECURITY_FILE_CAPABILITIES setting, CAP_SETPCAP allows crazy cap-setting silliness, and is disabled by init
 - with CONFIG_SECURITY_FILE_CAPABILITIES, CAP_SETPCAP behaves differently, so it is not disabled by init

What I'd like to understand this better is an example of a "vulnerable" and "safe" behavior. From there, I can build a kernel both ways, and verify that CONFIG_SECURITY_FILE_CAPABILITIES is still safe.

Can someone give me an example to use that demonstrates the dangerous behavior?

With CONFIG_SECURITY_FILE_CAPABILITIES=n, a task with CAP_SETPCAP can grant capabilities from its permitted set to any other process id, or remove them.

This means that a local attacker can attack any vulnerable root-owned service and coerce it into giving its permitted capabilities to the attacker.

If you wanted to verify that with a testcase, easiest thing is probably just to write a program that does something like

int main(int argc, char *argv[])
{
   pid = atoi(argv[1]);
   cap_t mycaps = cap_from_text("all=p");
   capsetp(pid, mycaps);
   cap_free(mycaps);
}

(untested and uncompiled). Start one root and one non-root shell, and from the root shell run the above with the process id of the non-root shell, then cat /proc/self/status from the non-root shell and look at your caps.

But I'm not clear on what you're trying to prove. Basically all I want is to have CONFIG_SECURITY_FILE_CAPABILITIES=y in my default hardy kernel. Are you trying to prove to yourself that that is safe? If you're trying to do a detailed review of the security
decisions with the file capabilities, there are other things to consider as well...

I just noticed that this bug is about the whole CAP_SETCAP and not only about CONFIG_SECURITY_FILE_CAPABILITIES :) The latter brought me here because my bug 232351 got marked as a duplicate of this one.

Examples for safe behaviour are for example bug 103010: "Starting with Linux 2.6.18, the kernel now requires that a user process has CAP_NET_ADMIN capability associated with it to set persistent tap interfaces. This a problem since most people do not run qemu as root - nor should they."

Check out http://www.friedhoff.org/posixfilecaps.html for more details.

On Thu, Jun 19, 2008 at 09:53:18PM -0000, Serge Hallyn wrote:
> int main(int argc, char *argv[])
> {
> pid = atoi(argv[1]);
> cap_t mycaps = cap_from_text("all=p");
> capsetp(pid, mycaps);
> cap_free(mycaps);
> }

Ah, good. This is helpful, thanks. :)

CONFIG_SECURITY_FILE_CAPABILITIES is enabled in the Intrepid kernel.

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.