Re: [kernel-hardening] [PATCH] lib: harden strncpy_from_user

[Loganaden Velvindron]

On Mon, Oct 17, 2016 at 5:04 PM, Mark Rutland  wrote:
> On Fri, Aug 26, 2016 at 02:57:58PM -0400, Kees Cook wrote:
>> On Fri, Aug 26, 2016 at 10:31 AM, Mark Rutland  wrote:
>> > The strncpy_from_user() accessor is effectively a copy_from_user()
>> > specialised to copy strings, terminating early at a NUL byte if
>> > possible. In other respects it is identical, and can be used to copy an
>> > arbitrarily large buffer from userspace into the kernel. Conceptually,
>> > it exposes a similar attack surface.
>> >
>> > As with copy_from_user(), we check the destination range when the kernel
>> > is built with KASAN, but unlike copy_from_user() we do not check the
>> > destination buffer when using HARDENED_USERCOPY. As strncpy_from_user()
>> > calls get_user() in a loop, we must call check_object_size() explicitly.
>> >
>> > This patch adds this instrumentation to strncpy_from_user(), per the
>> > same rationale as with the regular copy_from_user(). In the absence of
>> > hardened usercopy this will have no impact as the instrumentation
>> > expands to an empty static inline function.
>
> [...]
>
>> Ah, yes, good catch! (And to repeat what you mentioned to me in
>> passing in the hall: there appear to be other users of get_user() in a
>> loop in other places in the kernel that will likely need some
>> attention too.)
>
> I was reminded of this as it just hit mainline; is it worth dropping a
> TODO on the KSPP wiki? I suspect I won't have the time to delve much
> further into this in the near term, and it might be a good intro task
> for someone.
>
> Thanks,
> Mark.

Yes. I believe that it is.

Re: [kernel-hardening] [PATCH] lib: harden strncpy_from_user

[Loganaden Velvindron]

On Mon, Oct 17, 2016 at 5:04 PM, Mark Rutland  wrote:
> On Fri, Aug 26, 2016 at 02:57:58PM -0400, Kees Cook wrote:
>> On Fri, Aug 26, 2016 at 10:31 AM, Mark Rutland  wrote:
>> > The strncpy_from_user() accessor is effectively a copy_from_user()
>> > specialised to copy strings, terminating early at a NUL byte if
>> > possible. In other respects it is identical, and can be used to copy an
>> > arbitrarily large buffer from userspace into the kernel. Conceptually,
>> > it exposes a similar attack surface.
>> >
>> > As with copy_from_user(), we check the destination range when the kernel
>> > is built with KASAN, but unlike copy_from_user() we do not check the
>> > destination buffer when using HARDENED_USERCOPY. As strncpy_from_user()
>> > calls get_user() in a loop, we must call check_object_size() explicitly.
>> >
>> > This patch adds this instrumentation to strncpy_from_user(), per the
>> > same rationale as with the regular copy_from_user(). In the absence of
>> > hardened usercopy this will have no impact as the instrumentation
>> > expands to an empty static inline function.
>
> [...]
>
>> Ah, yes, good catch! (And to repeat what you mentioned to me in
>> passing in the hall: there appear to be other users of get_user() in a
>> loop in other places in the kernel that will likely need some
>> attention too.)
>
> I was reminded of this as it just hit mainline; is it worth dropping a
> TODO on the KSPP wiki? I suspect I won't have the time to delve much
> further into this in the near term, and it might be a good intro task
> for someone.
>
> Thanks,
> Mark.

Yes. I believe that it is.

Re: [RFC PATCH 00/11] Adding FreeBSD's Capsicum security framework (part 1)

[Loganaden Velvindron]

On Thu, Jul 3, 2014 at 1:12 PM, Paolo Bonzini  wrote:
> Il 30/06/2014 12:28, David Drysdale ha scritto:
>>
>> Hi all,
>>
>> The last couple of versions of FreeBSD (9.x/10.x) have included the
>> Capsicum security framework [1], which allows security-aware
>> applications to sandbox themselves in a very fine-grained way.  For
>> example, OpenSSH now (>= 6.5) uses Capsicum in its FreeBSD version to
>> restrict sshd's credentials checking process, to reduce the chances of
>> credential leakage.

Aside from OpenSSH, I've also been working on implementing Capsicum,
in other userspace software.



>
>
> Hi David,
>
> we've had similar goals in QEMU.  QEMU can be used as a virtual machine
> monitor from the command line, but it also has an API that lets a management
> tool drive QEMU via AF_UNIX sockets.  Long term, we would like to have a
> restricted mode for QEMU where all file descriptors are obtained via
> SCM_RIGHTS or /dev/fd, and syscalls can be locked down.
>
> Currently we do use seccomp v2 BPF filters, but unfortunately this didn't
> help very much.  QEMU supports hotplugging hence the filter must whitelist
> anything that _might_ be used in the future, which is generally... too much.
>
> Something like Capsicum would be really nice because it attaches
> capabilities to file descriptors.  However, I wonder however how extensible
> Capsicum could be, and I am worried about the proliferation of capabilities
> that its design naturally leads to.
>
> Given Linux's previous experience with BPF filters, what do you think about
> attaching specific BPF programs to file descriptors?  Then whenever a
> syscall is run that affects a file descriptor, the BPF program for the file
> descriptor (attached to a struct file* as in Capsicum) would run in addition
> to the process-wide filter.
>
> An equivalent of PR_SET_NO_NEW_PRIVS can also be added to file descriptors,
> so that a program that doesn't lock down syscalls can still lock down the
> operations (including fcntls and ioctls) on specific file descriptors.
>
> Converting FreeBSD capabilities to BPF programs can be easily implemented in
> userspace.
>
>>   [Capsicum also includes 'capability mode', which locks down the
>>   available syscalls so the rights restrictions can't just be bypassed
>>   by opening new file descriptors; I'll describe that separately later.]
>
>
> This can also be implemented in userspace via seccomp and
> PR_SET_NO_NEW_PRIVS.
>
>>   [Policing the rights checks anywhere else, for example at the system
>>   call boundary, isn't a good idea because it opens up the possibility
>>   of time-of-check/time-of-use (TOCTOU) attacks [2] where FDs are
>>   changed (as openat/close/dup2 are allowed in capability mode) between
>>   the 'check' at syscall entry and the 'use' at fget() invocation.]
>
>
> In the case of BPF filters, I wonder if you could stash the BPF
> "environment" somewhere and then use it at fget() invocation. Alternatively,
> it can be reconstructed at fget() time, similar to your introduction of
> fgetr().
>
> Thanks,
>
> Paolo
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-security-module" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 00/11] Adding FreeBSD's Capsicum security framework (part 1)

[Loganaden Velvindron]

On Thu, Jul 3, 2014 at 1:12 PM, Paolo Bonzini pbonz...@redhat.com wrote:
 Il 30/06/2014 12:28, David Drysdale ha scritto:

 Hi all,

 The last couple of versions of FreeBSD (9.x/10.x) have included the
 Capsicum security framework [1], which allows security-aware
 applications to sandbox themselves in a very fine-grained way.  For
 example, OpenSSH now (= 6.5) uses Capsicum in its FreeBSD version to
 restrict sshd's credentials checking process, to reduce the chances of
 credential leakage.

Aside from OpenSSH, I've also been working on implementing Capsicum,
in other userspace software.





 Hi David,

 we've had similar goals in QEMU.  QEMU can be used as a virtual machine
 monitor from the command line, but it also has an API that lets a management
 tool drive QEMU via AF_UNIX sockets.  Long term, we would like to have a
 restricted mode for QEMU where all file descriptors are obtained via
 SCM_RIGHTS or /dev/fd, and syscalls can be locked down.

 Currently we do use seccomp v2 BPF filters, but unfortunately this didn't
 help very much.  QEMU supports hotplugging hence the filter must whitelist
 anything that _might_ be used in the future, which is generally... too much.

 Something like Capsicum would be really nice because it attaches
 capabilities to file descriptors.  However, I wonder however how extensible
 Capsicum could be, and I am worried about the proliferation of capabilities
 that its design naturally leads to.

 Given Linux's previous experience with BPF filters, what do you think about
 attaching specific BPF programs to file descriptors?  Then whenever a
 syscall is run that affects a file descriptor, the BPF program for the file
 descriptor (attached to a struct file* as in Capsicum) would run in addition
 to the process-wide filter.

 An equivalent of PR_SET_NO_NEW_PRIVS can also be added to file descriptors,
 so that a program that doesn't lock down syscalls can still lock down the
 operations (including fcntls and ioctls) on specific file descriptors.

 Converting FreeBSD capabilities to BPF programs can be easily implemented in
 userspace.

   [Capsicum also includes 'capability mode', which locks down the
   available syscalls so the rights restrictions can't just be bypassed
   by opening new file descriptors; I'll describe that separately later.]


 This can also be implemented in userspace via seccomp and
 PR_SET_NO_NEW_PRIVS.

   [Policing the rights checks anywhere else, for example at the system
   call boundary, isn't a good idea because it opens up the possibility
   of time-of-check/time-of-use (TOCTOU) attacks [2] where FDs are
   changed (as openat/close/dup2 are allowed in capability mode) between
   the 'check' at syscall entry and the 'use' at fget() invocation.]


 In the case of BPF filters, I wonder if you could stash the BPF
 environment somewhere and then use it at fget() invocation. Alternatively,
 it can be reconstructed at fget() time, similar to your introduction of
 fgetr().

 Thanks,

 Paolo
 --
 To unsubscribe from this list: send the line unsubscribe
 linux-security-module in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)

[Loganaden Velvindron]

On Tue, Jul 1, 2014 at 1:53 PM, David Drysdale  wrote:
> On Mon, Jun 30, 2014 at 01:40:40PM -0700, Andi Kleen wrote:
>> David Drysdale  writes:
>>
>> > Add a new O_BENEATH_ONLY flag for openat(2) which restricts the
>> > provided path, rejecting (with -EACCES) paths that are not beneath
>> > the provided dfd.  In particular, reject:
>> >  - paths that contain .. components
>> >  - paths that begin with /
>> >  - symlinks that have paths as above.
>>
>> How about bind mounts?
>>
>> -Andi
>>
>> --
>> a...@linux.intel.com -- Speaking for myself only
>
> Bind mounts won't get rejected because they just look like normal
> path components.  In other words, if dir/subdir is a bind mount to
> /root/dir then:
>   fd = openat(AT_FDCWD, "dir/subdir", O_RDONLY|O_BENEATH_ONLY);
> will work fine.

Talking about David's efforts at porting Capsicum to Linux, I've
already implemented
support for Capsicum in OpenSSH. It shouldn't be complicated to enable
it on Linux
systems that support it.

I would very like to see capsicum integrated into mainline, as it's a
high quality sandbox
solution, that will benefit a lot of server software that implement
privilege separation.




> --
> To unsubscribe from this list: send the line "unsubscribe 
> linux-security-module" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)

[Loganaden Velvindron]

On Tue, Jul 1, 2014 at 1:53 PM, David Drysdale drysd...@google.com wrote:
 On Mon, Jun 30, 2014 at 01:40:40PM -0700, Andi Kleen wrote:
 David Drysdale drysd...@google.com writes:

  Add a new O_BENEATH_ONLY flag for openat(2) which restricts the
  provided path, rejecting (with -EACCES) paths that are not beneath
  the provided dfd.  In particular, reject:
   - paths that contain .. components
   - paths that begin with /
   - symlinks that have paths as above.

 How about bind mounts?

 -Andi

 --
 a...@linux.intel.com -- Speaking for myself only

 Bind mounts won't get rejected because they just look like normal
 path components.  In other words, if dir/subdir is a bind mount to
 /root/dir then:
   fd = openat(AT_FDCWD, dir/subdir, O_RDONLY|O_BENEATH_ONLY);
 will work fine.

Talking about David's efforts at porting Capsicum to Linux, I've
already implemented
support for Capsicum in OpenSSH. It shouldn't be complicated to enable
it on Linux
systems that support it.

I would very like to see capsicum integrated into mainline, as it's a
high quality sandbox
solution, that will benefit a lot of server software that implement
privilege separation.




 --
 To unsubscribe from this list: send the line unsubscribe 
 linux-security-module in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/