Re: [PATCH v4 0/2] Control over userfaultfd kernel-fault handling

if through selinux, seccomp or a > different sysctl value, without this patchset applied the default > behavior of the userfaultfd syscall for all Linux binaries running on > Android kernels, would deviate from the upstream kernel. So even if we > would make the pipe mutex logic more complex the deviation would > remain. Your patchset adds much less risk of breakage than adding a > timeout to kernel initiated userfaults and it resolves all concerns as > well as a timeout. We'll also make better use of the "0" value this > way. So while I'm not certain this is the best for the long term, this > looks the sweet spot for the short term to resolve many issues at > once. > > Thanks! > Andrea > -- Nick Kralevich | n...@google.com

Re: [PATCH 2/2] Add a new sysctl knob: unprivileged_userfaultfd_user_mode_only

an exploit writer (see explanation at https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cefdca0a86be517bc390fc4541e3674b8e7803b0 or https://duasynt.com/blog/cve-2016-6187-heap-off-by-one-exploit) [3] https://android.googlesource.com/platform/system/sepolicy/+/7be9e9e372c70a5518f729a0cdcb0d39a28be377/private/domain.te#107 line 107 -- Nick Kralevich | n...@google.com

Re: [PATCH 2/2] Add a new sysctl knob: unprivileged_userfaultfd_user_mode_only

On Fri, Jul 24, 2020 at 6:40 AM Michael S. Tsirkin wrote: > > On Thu, Jul 23, 2020 at 05:13:28PM -0700, Nick Kralevich wrote: > > On Thu, Jul 23, 2020 at 10:30 AM Lokesh Gidra > > wrote: > > > From the discussion so far it seems that there is a consensus that >

Re: [PATCH 2/2] Add a new sysctl knob: unprivileged_userfaultfd_user_mode_only

at bug is present by processes being unprotected by seccomp? Seccomp cannot be universally applied on Android due to previously mentioned performance concerns. Seccomp is used in Android primarily as a tool to enforce the list of allowed syscalls, so that such syscalls can be audited before being included as part of the Android API. -- Nick -- Nick Kralevich | n...@google.com

Re: [kernel-hardening] [PATCH] fs: Use CAP_DAC_OVERRIDE to allow for file dedupe

the elements will ensure that the CAP_DAC_OVERRIDE denial (least permissive) is generated first. > u16 count = same->dest_count; > struct file *dst_file; > loff_t dst_off; > -- > 2.14.2 > -- Nick Kralevich | Android Security | n...@google.com | 650.214.4037

Re: [kernel-hardening] [PATCH] fs: Use CAP_DAC_OVERRIDE to allow for file dedupe

ial (least permissive) is generated first. > u16 count = same->dest_count; > struct file *dst_file; > loff_t dst_off; > -- > 2.14.2 > -- Nick Kralevich | Android Security | n...@google.com | 650.214.4037

Re: [kernel-hardening] Re: [PATCHv3 2/2] extract early boot entropy from the passed cmdline

On Wed, Aug 30, 2017 at 2:57 AM, Pavel Machek <pa...@ucw.cz> wrote: > The command line is visible to unpriviledged userspace (/proc/cmdline, > dmesg). Is that a problem? These files are not exposed to untrusted processes on Android. -- Nick Kralevich | Android Security | n..

Re: [kernel-hardening] Re: [PATCHv3 2/2] extract early boot entropy from the passed cmdline

On Wed, Aug 30, 2017 at 2:57 AM, Pavel Machek wrote: > The command line is visible to unpriviledged userspace (/proc/cmdline, > dmesg). Is that a problem? These files are not exposed to untrusted processes on Android. -- Nick Kralevich | Android Security | n...@google.com | 650.214.4037

Re: [kernel-hardening] [PATCHv2 2/2] extract early boot entropy from the passed cmdline

On Wed, Aug 16, 2017 at 3:46 PM, Laura Abbott wrote: > From: Daniel Micay > > Existing Android bootloaders usually pass data useful as early entropy > on the kernel command-line. It may also be the case on other embedded > systems. Sample command-line

Re: [kernel-hardening] [PATCHv2 2/2] extract early boot entropy from the passed cmdline

On Wed, Aug 16, 2017 at 3:46 PM, Laura Abbott wrote: > From: Daniel Micay > > Existing Android bootloaders usually pass data useful as early entropy > on the kernel command-line. It may also be the case on other embedded > systems. Sample command-line from a Google Pixel running CopperheadOS: >

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

TQ FIOCLEX TCGETS TCSETS TIOCGWINSZ TIOCSWINSZ TIOCSCTTY TCSETSW TCFLSH TIOCSPGRP TIOCGPGRP See unpriv_tty_ioctls at https://android.googlesource.com/platform/system/sepolicy/+/34b4b73729b288b4109b2225c1445eb58393b8cb/public/ioctl_macros#51 -- Nick Kralevich | Android Security | n..

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

GWINSZ TIOCSWINSZ TIOCSCTTY TCSETSW TCFLSH TIOCSPGRP TIOCGPGRP See unpriv_tty_ioctls at https://android.googlesource.com/platform/system/sepolicy/+/34b4b73729b288b4109b2225c1445eb58393b8cb/public/ioctl_macros#51 -- Nick Kralevich | Android Security | n...@google.com | 650.214.4037

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On Tue, May 30, 2017 at 11:32 AM, Stephen Smalley wrote: >> Seccomp requires the program in question to "opt-in" so to speak and >> set >> certain restrictions on itself. However as you state above, any >> TIOCSTI >> protection doesn't matter if the program correctly allocates

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On Tue, May 30, 2017 at 11:32 AM, Stephen Smalley wrote: >> Seccomp requires the program in question to "opt-in" so to speak and >> set >> certain restrictions on itself. However as you state above, any >> TIOCSTI >> protection doesn't matter if the program correctly allocates a >> tty/pty pair.

Re: [Regression?] 1ea0ce4069 ("selinux: allow changing labels for cgroupfs") stops Android from booting

gt; it to be enabled only if the policy correctly supports it. Even > better, we should instead just allow the policy to specify which > filesystems should support this behavior (already on the issues list). > If Android is the only system affected by this bug, I would prefer to just fix Android to allow for this patch, rather than having additional kernel complexity. -- Nick Kralevich | Android Security | n...@google.com | 650.214.4037

Re: [Regression?] 1ea0ce4069 ("selinux: allow changing labels for cgroupfs") stops Android from booting

licy correctly supports it. Even > better, we should instead just allow the policy to specify which > filesystems should support this behavior (already on the issues list). > If Android is the only system affected by this bug, I would prefer to just fix Android to allow for this patch, rather than having additional kernel complexity. -- Nick Kralevich | Android Security | n...@google.com | 650.214.4037

Re: [Regression?] 1ea0ce4069 ("selinux: allow changing labels for cgroupfs") stops Android from booting

roid test system to play with, have >> any of the SEAndroid folks on the To/CC line seen a similar problem? > > So from my very limited knowledge here, adding the patch in question > seems to make the cgroup mount get the SBLABEL_MNT flag? > Which I'm guessing this is causing additional selinux restrictions on > processes accessing cgroup mounts, which causes some of the early > initialization processes to fail? > > Should this change mean the selinux policy needs to be updated? > > thanks > -john -- Nick Kralevich | Android Security | n...@google.com | 650.214.4037

Re: [Regression?] 1ea0ce4069 ("selinux: allow changing labels for cgroupfs") stops Android from booting

a similar problem? > > So from my very limited knowledge here, adding the patch in question > seems to make the cgroup mount get the SBLABEL_MNT flag? > Which I'm guessing this is causing additional selinux restrictions on > processes accessing cgroup mounts, which causes some of the early > initialization processes to fail? > > Should this change mean the selinux policy needs to be updated? > > thanks > -john -- Nick Kralevich | Android Security | n...@google.com | 650.214.4037

Re: [PATCH] [RFC] Introduce mmap randomization

On Tue, Aug 2, 2016 at 9:57 AM, Roberts, William C <william.c.robe...@intel.com> wrote: > @nnk, disabling ASLR via set_arch() on Android, is that only for 32 bit > address spaces where > you had that problem? Yes. Only 32 bit address spaces had the fragmentation problem. --

Re: [PATCH] [RFC] Introduce mmap randomization

On Tue, Aug 2, 2016 at 9:57 AM, Roberts, William C wrote: > @nnk, disabling ASLR via set_arch() on Android, is that only for 32 bit > address spaces where > you had that problem? Yes. Only 32 bit address spaces had the fragmentation problem. -- Nick Kralevich | Android Sec

Re: [PATCH] [RFC] Introduce mmap randomization

ve Hansen's suggestion that this functionality be limited to 64 bits, where concerns about running out of address space are essentially nil. I'd be supportive of this change if it was limited to 64 bits. -- Nick -- Nick Kralevich | Android Security | n...@google.com | 650.214.4037

Re: [PATCH] [RFC] Introduce mmap randomization

that this functionality be limited to 64 bits, where concerns about running out of address space are essentially nil. I'd be supportive of this change if it was limited to 64 bits. -- Nick -- Nick Kralevich | Android Security | n...@google.com | 650.214.4037

Re: [PATCH] [RFC] Introduce mmap randomization

On Tue, Jul 26, 2016 at 2:02 PM, Roberts, William C <william.c.robe...@intel.com> wrote: > > >> -Original Message----- >> From: Nick Kralevich [mailto:n...@google.com] >> Sent: Tuesday, July 26, 2016 1:41 PM >> To: Roberts, William C <william.c.robe...

Re: [PATCH] [RFC] Introduce mmap randomization

On Tue, Jul 26, 2016 at 2:02 PM, Roberts, William C wrote: > > >> -Original Message----- >> From: Nick Kralevich [mailto:n...@google.com] >> Sent: Tuesday, July 26, 2016 1:41 PM >> To: Roberts, William C >> Cc: ja...@lakedaemon.net; linux...@vger.kerne

Re: [PATCH] [RFC] Introduce mmap randomization

lign_offset - gap_start) & info->align_mask; > > @@ -1775,6 +1796,9 @@ found: > found_highest: > /* Compute highest gap address at the desired alignment */ > gap_end -= info->length; > + > + gap_end = randomize_mmap(gap_start, gap_end, length) ? : gap_end; > + > gap_end -= (gap_end - info->align_offset) & info->align_mask; > > VM_BUG_ON(gap_end < info->low_limit); > -- > 1.9.1 > -- Nick Kralevich | Android Security | n...@google.com | 650.214.4037

Re: [PATCH] [RFC] Introduce mmap randomization

_highest: > /* Compute highest gap address at the desired alignment */ > gap_end -= info->length; > + > + gap_end = randomize_mmap(gap_start, gap_end, length) ? : gap_end; > + > gap_end -= (gap_end - info->align_offset) & info->align_mask; > > VM_BUG_ON(gap_end < info->low_limit); > -- > 1.9.1 > -- Nick Kralevich | Android Security | n...@google.com | 650.214.4037

Re: [RFC][PATCH 2/2 v3] security: Add task_settimerslack/task_gettimerslack LSM hook

. > > I've kept the CAP_SYS_NICE check in the timerslack_ns_write/show > functions, as hiding it in the LSM hook seems too opaque, and doesn't > seem like a widely enough adopted practice. > > Don't really know what I'm doing here, so close review would be > appreciated! Looks good. Tha

Re: [RFC][PATCH 2/2 v3] security: Add task_settimerslack/task_gettimerslack LSM hook

_SYS_NICE check in the timerslack_ns_write/show > functions, as hiding it in the LSM hook seems too opaque, and doesn't > seem like a widely enough adopted practice. > > Don't really know what I'm doing here, so close review would be > appreciated! Looks good. Thanks! Reviewed-by: Nick Krale

Re: [RFC][PATCH 1/2 v3] proc: Relax /proc//timerslack_ns capability requirements

his patch loosens the capability requirements to > CAP_SYS_NICE and removes CAP_SYS_PTRACE, simplifying some > of the code flow as well. > > This is technically an ABI change, but as the feature just > landed in 4.6, I suspect no one is yet using it. Looks good. Thanks! Reviewed-by:

Re: [RFC][PATCH 1/2 v3] proc: Relax /proc//timerslack_ns capability requirements

capability requirements to > CAP_SYS_NICE and removes CAP_SYS_PTRACE, simplifying some > of the code flow as well. > > This is technically an ABI change, but as the feature just > landed in 4.6, I suspect no one is yet using it. Looks good. Thanks! Reviewed-by: Nick Kralevich > >

Re: [RFC][PATCH 1/2 v2] proc: Relax /proc//timerslack_ns capability requirements

On Fri, Jul 15, 2016 at 1:03 PM, John Stultz <john.stu...@linaro.org> wrote: > On Fri, Jul 15, 2016 at 12:55 PM, Nick Kralevich <n...@google.com> wrote: >> This should also have a similar LSM check for reads. For the SELinux >> implementation, this can map to the P

Re: [RFC][PATCH 1/2 v2] proc: Relax /proc//timerslack_ns capability requirements

On Fri, Jul 15, 2016 at 1:03 PM, John Stultz wrote: > On Fri, Jul 15, 2016 at 12:55 PM, Nick Kralevich wrote: >> This should also have a similar LSM check for reads. For the SELinux >> implementation, this can map to the PROCESS__GETSCHED permission. > > Ok. I'll wire that

Re: [RFC][PATCH 1/2 v2] proc: Relax /proc//timerslack_ns capability requirements

gt; Cc: Ruchi Kandoi <kandoiru...@google.com> > Cc: Rom Lemarchand <rom...@android.com> > Cc: Todd Kjos <tk...@google.com> > Cc: Colin Cross <ccr...@android.com> > Cc: Nick Kralevich <n...@google.com> > Cc: Dmitry Shmidt <dimitr...@google.com> > Cc

Re: [RFC][PATCH 1/2 v2] proc: Relax /proc//timerslack_ns capability requirements

ot; > Cc: Andrew Morton > Cc: Thomas Gleixner > CC: Arjan van de Ven > Cc: Oren Laadan > Cc: Ruchi Kandoi > Cc: Rom Lemarchand > Cc: Todd Kjos > Cc: Colin Cross > Cc: Nick Kralevich > Cc: Dmitry Shmidt > Cc: Elliott Hughes > Cc: An

Re: [RFC][PATCH 2/2 v2] security: Add task_settimerslack LSM hook

an de Ven <ar...@linux.intel.com> > Cc: Oren Laadan <or...@cellrox.com> > Cc: Ruchi Kandoi <kandoiru...@google.com> > Cc: Rom Lemarchand <rom...@android.com> > Cc: Todd Kjos <tk...@google.com> > Cc: Colin Cross <ccr...@android.com> > Cc: Nick

Re: [RFC][PATCH 2/2 v2] security: Add task_settimerslack LSM hook

se review would be > appreciated! > > Cc: Kees Cook > Cc: "Serge E. Hallyn" > Cc: Andrew Morton > Cc: Thomas Gleixner > CC: Arjan van de Ven > Cc: Oren Laadan > Cc: Ruchi Kandoi > Cc: Rom Lemarchand > Cc: Todd Kjos > Cc: Colin Cross > Cc: Nick Kra

Re: [RFC][PATCH 1/2 v2] proc: Relax /proc//timerslack_ns capability requirements

gt; Cc: Ruchi Kandoi <kandoiru...@google.com> > Cc: Rom Lemarchand <rom...@android.com> > Cc: Todd Kjos <tk...@google.com> > Cc: Colin Cross <ccr...@android.com> > Cc: Nick Kralevich <n...@google.com> > Cc: Dmitry Shmidt <dimitr...@google.com> > Cc

Re: [RFC][PATCH 1/2 v2] proc: Relax /proc//timerslack_ns capability requirements

ot; > Cc: Andrew Morton > Cc: Thomas Gleixner > CC: Arjan van de Ven > Cc: Oren Laadan > Cc: Ruchi Kandoi > Cc: Rom Lemarchand > Cc: Todd Kjos > Cc: Colin Cross > Cc: Nick Kralevich > Cc: Dmitry Shmidt > Cc: Elliott Hughes > Cc: An

Re: [RFC][PATCH] proc: Relax /proc//timerslack_ns capability requirements

t;Serge E. Hallyn" <se...@hallyn.com> > Cc: Andrew Morton <a...@linux-foundation.org> > Cc: Thomas Gleixner <t...@linutronix.de> > CC: Arjan van de Ven <ar...@linux.intel.com> > Cc: Oren Laadan <or...@cellrox.com> > Cc: Ruchi Kandoi <kandoiru...@go

Re: [RFC][PATCH] proc: Relax /proc//timerslack_ns capability requirements

c: Thomas Gleixner > CC: Arjan van de Ven > Cc: Oren Laadan > Cc: Ruchi Kandoi > Cc: Rom Lemarchand > Cc: Todd Kjos > Cc: Colin Cross > Cc: Nick Kralevich > Cc: Dmitry Shmidt > Cc: Elliott Hughes > Cc: Android Kernel Team > Signed-off-by: John Stultz > ---

Re: [PATCH] mm: reorder can_do_mlock to fix audit denial

lock returns true. The capable check leads to an LSM > hook used by apparmour and selinux which produce the audit denial. > Reordering so rlimit is checked first eliminates the denial on success, > only recording a denial when the lock is unsuccessful as a result of > the denial. >

Re: [PATCH] mm: reorder can_do_mlock to fix audit denial

can_do_mlock returns true. The capable check leads to an LSM hook used by apparmour and selinux which produce the audit denial. Reordering so rlimit is checked first eliminates the denial on success, only recording a denial when the lock is unsuccessful as a result of the denial. Acked-By: Nick

Re: [PATCH] avc: remove unnecessary pointer reassignment

Acked-By: Nick Kralevich On Thu, Feb 26, 2015 at 1:54 PM, Jeff Vander Stoep wrote: > Commit f01e1af445fa ("selinux: don't pass in NULL avd to > avc_has_perm_noaudit") > made this pointer reassignment unnecessary. Avd should continue to reference > the stack-based copy. &

Re: [PATCH] avc: remove unnecessary pointer reassignment

Acked-By: Nick Kralevich n...@google.com On Thu, Feb 26, 2015 at 1:54 PM, Jeff Vander Stoep je...@google.com wrote: Commit f01e1af445fa (selinux: don't pass in NULL avd to avc_has_perm_noaudit) made this pointer reassignment unnecessary. Avd should continue to reference the stack-based copy

Re: [PATCH] Add security hooks to binder and implement the hooks for SELinux.

Acked-By: Nick Kralevich On Thu, Jan 22, 2015 at 12:51 AM, Greg KH wrote: > On Wed, Jan 21, 2015 at 10:54:10AM -0500, Stephen Smalley wrote: >> Add security hooks to the binder and implement the hooks for SELinux. >> The security hooks enable security modules such as SELin

Re: [PATCH] Add security hooks to binder and implement the hooks for SELinux.

Acked-By: Nick Kralevich n...@google.com On Thu, Jan 22, 2015 at 12:51 AM, Greg KH gre...@linuxfoundation.org wrote: On Wed, Jan 21, 2015 at 10:54:10AM -0500, Stephen Smalley wrote: Add security hooks to the binder and implement the hooks for SELinux. The security hooks enable security modules