Skip to content

GitLab

Switch branch/tag
  1. 01 Nov, 2014 1 commit
    • Andy Lutomirski's avatar
      Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs · 14434eef
      Andy Lutomirski authored 
      
With this change, calling
  prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)
disables privilege granting operations at execve-time.  For example, a
process will not be able to execute a setuid binary to change their uid
or gid if this bit is set.  The same is true for file capabilities.

Additionally, LSM_UNSAFE_NO_NEW_PRIVS is defined to ensure that
LSMs respect the requested behavior.

To determine if the NO_NEW_PRIVS bit is set, a task may call
  prctl(PR_GET_NO_NEW_PRIVS, 0, 0, 0, 0);
It returns 1 if set and 0 if it is not set. If any of the arguments are
non-zero, it will return -1 and set errno to -EINVAL.
(PR_SET_NO_NEW_PRIVS behaves similarly.)

This functionality is desired for the proposed seccomp filter patch
series.  By using PR_SET_NO_NEW_PRIVS, it allows a task to modify the
system call behavior for itself and its child tasks without being
able to impact the behavior of a more privileged task.

Another potential use is making certain privileged operations
unprivileged.  For example, chroot may be considered "safe" if it cannot
affect privileged tasks.

Note, this patch causes execve to fail when PR_SET_NO_NEW_PRIVS is
set and AppArmor is in use.  It is fixed in a subsequent patch.
Signed-off-by: default avatarAndy Lutomirski <luto@amacapital.net>
Signed-off-by: default avatarWill Drewry <wad@chromium.org>
Acked-by: default avatarEric Paris <eparis@redhat.com>

v18: updated change desc
v17: using new define values as per 3.4

Conflicts:
	include/linux/prctl.h
	kernel/sys.c
      14434eef
  3. 14 Oct, 2014 1 commit
  5. 03 Oct, 2014 2 commits
  7. 16 Aug, 2014 10 commits
  9. 13 Aug, 2014 1 commit
  11. 05 Aug, 2014 3 commits
    • Minsung Kim's avatar
      cpufreq: fix sleeping in atomic context when realloc freq_table for all_time_in_state · 4e847771
      Minsung Kim authored 
      
Commit 40cf2f8 (cpufreq: Persist cpufreq time in state data across hotplug)
causes the following call trace to be spit on boot:

BUG: sleeping function called from invalid context at mm/slub.c:936
in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: swapper/0
CPU: 6 PID: 1 Comm: swapper/0 Not tainted 3.10.9-20140624.172707-eng-gd6c0f69-dirty #50
Backtrace:
[<c0012270>] (dump_backtrace+0x0/0x10c) from [<c001256c>] (show_stack+0x18/0x1c)
 r6:ffff1788 r5:c0c020c0 r4:e609c000 r3:00000000
[<c0012554>] (show_stack+0x0/0x1c) from [<c07a2970>] (dump_stack+0x20/0x28)
[<c07a2950>] (dump_stack+0x0/0x28) from [<c0057678>] (__might_sleep+0x104/0x120)
[<c0057574>] (__might_sleep+0x0/0x120) from [<c00ff000>] (__kmalloc_track_caller+0x144/0x274)
 r6:00000000 r5:e609c000 r4:e6802140
[<c00feebc>] (__kmalloc_track_caller+0x0/0x274) from [<c00da098>] (krealloc+0x58/0xb0)
[<c00da040>] (krealloc+0x0/0xb0) from [<c050266c>] (cpufreq_allstats_create+0x120/0x204)
 r8:e4c4ff00 r7:c0d266b8 r6:0013d620 r5:e4c4e600 r4:00000001
r3:e535d6d0
[<c050254c>] (cpufreq_allstats_create+0x0/0x204) from [<c0502e38>] (cpufreq_stat_notifier_policy+0xb8/0xd0)
[<c0502d80>] (cpufreq_stat_notifier_policy+0x0/0xd0) from [<c00517cc>] (notifier_call_chain+0x4c/0x8c)
 r5:00000000 r4:fffffffe
[<c0051780>] (notifier_call_chain+0x0/0x8c) from [<c00519fc>] (__blocking_notifier_call_chain+0x50/0x68)
 r8:c0cd4d00 r7:00000002 r6:e609dd7c r5:ffffffff r4:c0d25a4c
r3:ffffffff
[<c00519ac>] (__blocking_notifier_call_chain+0x0/0x68) from [<c0051a34>] (blocking_notifier_call_chain+0x20/0x28)
 r7:c0e24f30 r6:00000000 r5:e53e1e00 r4:e609dd7c
[<c0051a14>] (blocking_notifier_call_chain+0x0/0x28) from [<c0500fec>] (__cpufreq_set_policy+0xc0/0x1d0)
[<c0500f2c>] (__cpufreq_set_policy+0x0/0x1d0) from [<c0501308>] (cpufreq_add_dev_interface+0x20c/0x270)
 r7:00000008 r6:00000000 r5:e53e1e00 r4:e53e1e58
[<c05010fc>] (cpufreq_add_dev_interface+0x0/0x270) from [<c05016a8>] (cpufreq_add_dev+0x33c/0x420)
[<c050136c>] (cpufreq_add_dev+0x0/0x420) from [<c03604a4>] (subsys_interface_register+0x80/0xbc)
[<c0360424>] (subsys_interface_register+0x0/0xbc) from [<c050035c>] (cpufreq_register_driver+0x8c/0x194)

Change-Id: If77a656d0ea60a8fc4083283d104509fa6c07f8f
Signed-off-by: default avatarMinsung Kim <ms925.kim@samsung.com>
      4e847771
    • Ruchi Kandoi's avatar
      cpufreq: Persist cpufreq time in state data across hotplug · 4c944cad
      Ruchi Kandoi authored 
      
Cpufreq time_in_state data for all CPUs is made persistent across
hotplug and exposed to userspace via sysfs file
/sys/devices/system/cpu/cpufreq/all_time_in_state

Change-Id: I97cb5de24b6de16189bf8b5df9592d0a6e6ddf32
Signed-off-by: default avatarRuchi Kandoi <kandoiruchi@google.com>
      4c944cad
    • Ruchi Kandoi's avatar
      Power: Changes the permission to read only for sysfs file · 45107628
      Ruchi Kandoi authored 
      /sys/kernel/wakeup_reasons/last_resume_reason

Change-Id: If25e8e416ee9726996518b58b6551a61dc1591e3
Signed-off-by: default avatarRuchi Kandoi <kandoiruchi@google.com>
      45107628
  13. 25 Jul, 2014 1 commit
    • Stephen Smalley's avatar
      Enable setting security contexts on rootfs inodes. · 90411729
      Stephen Smalley authored 
      
rootfs (ramfs) can support setting of security contexts
by userspace due to the vfs fallback behavior of calling
the security module to set the in-core inode state
for security.* attributes when the filesystem does not
provide an xattr handler.  No xattr handler required
as the inodes are pinned in memory and have no backing
store.

This is useful in allowing early userspace to label individual
files within a rootfs while still providing a policy-defined
default via genfs.
Signed-off-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      90411729
  15. 24 Jul, 2014 3 commits
    • Hans de Goede's avatar
      cgroup: Fix use after free of cgrp (cgrp->css_sets) · 565b635c
      Hans de Goede authored 
      
Running a 3.4 kernel + Fedora-18 (systemd) userland on my Allwinner A10
(arm cortex a8), I'm seeing repeated, reproducable list_del list corruption
errors when build with CONFIG_DEBUG_LIST, and the backtrace always shows
free_css_set_work as the function making the problematic list_del call.

I've tracked this doen to a use after free of the cgrp struct, specifically
of the cgrp->css_sets list_head, which gets cleared by free_css_set_work.

Since free_css_set_work runs form a workqueue, it is possible for it to not be
done with clearing the list when the cgrp gets free-ed. To avoid this the code
adding the links increases cgrp->count, and the freeing code running from the
workqueue decreases cgrp->count *after* doing list_del, and then if the count
goes to 0 calls cgroup_wakeup_rmdir_waiter().

However cgroup_rmdir() is missing a check for cgrp->count != 0, causing it
to still continue with the rmdir (which leads to the free-ing of the cgrp),
before free_css_set_work is done. Sometimes the free-ed memory is re-used
before free_css_set_work gets around to unlinking link->cgrp_link_list,
triggering the list_del list corruption messages.

This patch fixes this by properly checking for cgrp->count != 0 and waiting
for the cgroup_rmdir_waitq in that case.

Change-Id: I9dbc02a0a75d5dffa1b65d67456e00139dea57c3
Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      565b635c
    • Hans de Goede's avatar
      cgroup: Take css_set_lock from cgroup_css_sets_empty() · 0504ca2d
      Hans de Goede authored 
      
As indicated in the comment above cgroup_css_sets_empty it needs the
css_set_lock. But neither of the 2 call points have it, so rather then fixing
the callers just take the lock inside cgroup_css_sets_empty().
Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
Change-Id: If7aea71824f6d0e3f2cc6c1ce236c3ae6be2037b
      0504ca2d
    • Sasha Levin's avatar
      net/l2tp: don't fall back on UDP [get|set]sockopt · f7820fdf
      Sasha Levin authored 
      
The l2tp [get|set]sockopt() code has fallen back to the UDP functions
for socket option levels != SOL_PPPOL2TP since day one, but that has
never actually worked, since the l2tp socket isn't an inet socket.

As David Miller points out:

  "If we wanted this to work, it'd have to look up the tunnel and then
   use tunnel->sk, but I wonder how useful that would be"

Since this can never have worked so nobody could possibly have depended
on that functionality, just remove the broken code and return -EINVAL.
Reported-by: default avatarSasha Levin <sasha.levin@oracle.com>
Acked-by: default avatarJames Chapman <jchapman@katalix.com>
Acked-by: default avatarDavid Miller <davem@davemloft.net>
Cc: Phil Turnbull <phil.turnbull@oracle.com>
Cc: Vegard Nossum <vegard.nossum@oracle.com>
Cc: Willy Tarreau <w@1wt.eu>
Cc: stable@vger.kernel.org
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: default avatarEd Tam <etam@google.com>
      f7820fdf
  17. 18 Jul, 2014 7 commits
  19. 16 Jul, 2014 6 commits
  21. 15 Jul, 2014 1 commit
  23. 11 Jul, 2014 1 commit
  25. 09 Jul, 2014 1 commit
  27. 08 Jul, 2014 2 commits