Serge E. Hallyn | 27 May 09:18 2016

[PATCH] user-namespaced file capabilities - now with even more magic

Root in a user ns cannot be trusted to write a traditional
security.capability xattr.  If it were allowed to do so, then any
unprivileged user on the host could map his own uid to root in a
namespace, write the xattr, and execute the file with privilege on the
host.

This patch introduces v3 of the security.capability xattr.  It builds a
vfs_ns_cap_data struct by appending a uid_t rootid to struct
vfs_cap_data.  This is the absolute uid_t (i.e. the uid_t in
init_user_ns) of the root id (uid 0 in a namespace) in whose namespaces
the file capabilities may take effect.

When a task in a user ns (which is privileged with CAP_SETFCAP toward
that user_ns) asks to write v2 security.capability, the kernel will
transparently rewrite the xattr as a v3 with the appropriate rootid.
Subsequently, any task executing the file which has the noted kuid as
its root uid, or which is in a descendent user_ns of such a user_ns,
will run the file with capabilities.

If a task writes a v3 security.capability, then it can provide a
uid (valid within its own user namespace, over which it has CAP_SETFCAP)
for the xattr.  The kernel will translate that to the absolute uid, and
write that to disk.  After this, a task in the writer's namespace will
not be able to use those capabilities, but a task in a namespace where
the given uid is root will.

Only a single security.capability xattr may be written.  A task may
overwrite the existing one so long as it was written by a user mapped
into his own user_ns over which he has CAP_SETFCAP.

(Continue reading)

MRS. LIRA MANDOZA | 22 May 21:11 2016

THIS IS FROM MRS. LIRA MANDOZA


PLEASE KINDLY READ MY EMAIL ATTACHMENT AND GET BACK TO ME. I NEED YOUR ASSISTANCE.
Attachment (Mrs Lira Mandoza.pdf): application/pdf, 197 KiB
Andreas Gruenbacher | 10 May 00:02 2016
Picon

[PATCH v21 00/22] Richacls

Al,

here is an update to the richacl patches.  Changes since the last posting
(https://lwn.net/Articles/680388/):

 * Rebase on top of work.acl [*].  Minor restructuring of the functions
   accessing the cached ACLs in inodes.

[*] https://git.kernel.org/cgit/linux/kernel/git/viro/vfs.git/log/?h=work.acl

The complete patch queue is available here:

  git://git.kernel.org/pub/scm/linux/kernel/git/agruen/linux-richacl.git \
        richacl-2016-05-10

The richacl user-space utilitites, man pages, and test suite are available
here:

  https://github.com/andreas-gruenbacher/richacl

Changes to other user-space packages for richacl:

  https://github.com/andreas-gruenbacher/coreutils
  https://github.com/andreas-gruenbacher/e2fsprogs
  https://github.com/andreas-gruenbacher/samba
  https://github.com/andreas-gruenbacher/xfsprogs-dev
  https://github.com/andreas-gruenbacher/nfs-utils

Please see the richacl homepage for more information:

(Continue reading)

Tadeusz Struk | 5 May 21:50 2016
Picon

[PATCH RESEND v5 0/6] crypto: algif - add akcipher

First four patches are a resend of the v3 algif_akcipher from
Stephan Mueller, with minor changes after rebase on top of 4.6-rc1.

The next three patches add support for keys stored in system
keyring subsystem.

First patch adds algif_akcipher nokey hadlers.

Second patch adds generic sign, verify, encrypt, decrypt accessors
functions to the asymmetric key type. These will be defined by
asymmetric subtypes, similarly to how public_key currently defines
the verify_signature function.

Third patch adds support for ALG_SET_KEY_ID and ALG_SET_PUBKEY_ID
commands to AF_ALG and setkeyid operation to the af_alg_type struct.
If the keyid is used then the afalg layer acquires the key for the
keyring subsystem and uses the new asymmetric accessor functions
instead of akcipher api. The asymmetric subtypes can use akcipher
api internally.

This is the same v5 version as before rebased on top of
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-asym-keyctl

v5 changes:
- drop public key changes and use new version provided by David

v4 changes:
- don't use internal public_key struct in af_alg.
- add generic accessor functions to asymmetric key type, which take
  the generic struct key type and resolve the specific subtype internally
(Continue reading)

Darrick J. Wong | 5 May 21:47 2016
Picon

[RFC 0/3] getfsmapx ioctl

Hi,

Building on the discussion "Exposing Extent Information to Userspace"
at LSF, this patchset offers the userspace definition, implementation,
and manpages for a new FS_IOC_GETFSMAPX ioctl that enables userspace
to query the filesystem for a map of every extent in a given range of
physical block keyspace.

Note that prior to the existence of block sharing, I'd have said
"given range of physical blocks", but now that we can return multiple
owner:offset pairs for a given block, the block keyspace now has to
include extra fields to uniquely identify a reverse mapping record.

This ioctl behaves in a similar manner to XFS_IOC_GETBMAPX -- pass in
an array of struct getfsmapx with key and other control values in the
first two array elements, and the kernel passes back extent
information in the other array elements.  The particulars of how to do
this are documented in the manpage that goes along with this set (it
applies against man-pages.git) and example code in the other patches
is against xfsprogs.git#for-next.

Basically, set the lowest key for which you want records in the first
array element; the highest key in the second; and the kernel spits out
records in the rest of the elements.  That's similar to how GETBMAPX
does it, but different from FIEMAP.  I added a dummy 64-bit "device
id" per Josef's request, though I'm thinking that could be cut down to
a simple dev_t.  I also wonder if the kernel should rewrite the low
key with the last element returned so as to seed the next call, but
userspace can do that too.

(Continue reading)

serge.hallyn | 22 Apr 19:26 2016

namespaced file capabilities

Hi,

I've sent a few patches and emails over the past months about supporting
file capabilities in user namespace confined containers.  A few of the
requirements as I see them are:

1. Root in a user namespace should be able to set file capabilities on a binary
for use by any user mapped into his namespace.

2. Any uid not mapped into the user namespace whose root user set file
capabilities should not gain privileges when running an executable which only
has file capabilities set by this root user.

3. Existing calls to cap_set_file(3) and cap_get_file(3) as well as
setcap(8) and getcap(8) should transparently work.  This would allow
package managers to simply set file capabilities in postinst.

Below is a kernel patch which implements a new security.nscapability
extended attribute.  Setting this xattr on a file requires cap_setfcap
against the current user namespace, and for the file to be owned by
a uid and gid mapped into that namespace.  When found on a file,
the capabilities will take effect only if the file is owned by the
root uid in the caller's namespace, or the root uid in any ancestor
namespace.

While this design supports nested namespaces, it does not support
use of file capabilities by users in unrelated namespaces.  So if
the same file is linked into two namespaces N1 and N2 which do not
share the same root kuid, then the only way for N1 and N2 to both
execute the file while respecting security.nscapability is to have
(Continue reading)

Tadeusz Struk | 15 Apr 22:22 2016
Picon

[PATCH v5 0/6] crypto: algif - add akcipher

First four patches are a resend of the v3 algif_akcipher from
Stephan Mueller, with minor changes after rebase on top of 4.6-rc1.

The next three patches add support for keys stored in system
keyring subsystem.

First patch adds algif_akcipher nokey hadlers.

Second patch adds generic sign, verify, encrypt, decrypt accessors
functions to the asymmetric key type. These will be defined by
asymmetric subtypes, similarly to how public_key currently defines
the verify_signature function. 

Third patch adds support for ALG_SET_KEY_ID and ALG_SET_PUBKEY_ID
commands to AF_ALG and setkeyid operation to the af_alg_type struct.
If the keyid is used then the afalg layer acquires the key for the
keyring subsystem and uses the new asymmetric accessor functions
instead of akcipher api. The asymmetric subtypes can use akcipher
api internally.

Patches generated on top of 
https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-next
plus this:
https://patchwork.kernel.org/patch/8843381/

v5 changes:
- drop public key changes and use new version provided by David
- rebase on key-next and https://patchwork.kernel.org/patch/8843381/

v4 changes:
(Continue reading)

Petr Mladek | 14 Apr 17:14 2016
Gravatar

[PATCH v6 00/20] kthread: Use kthread worker API more widely

My intention is to make it easier to manipulate and maintain kthreads.
Especially, I want to replace all the custom main cycles with a
generic one. Also I want to make the kthreads sleep in a consistent
state in a common place when there is no work.

My first attempt was with a brand new API (iterant kthread), see
http://thread.gmane.org/gmane.linux.kernel.api/11892 . But I was
directed to improve the existing kthread worker API. This is
the 4th iteration of the new direction.

1nd..10th patches: improve the existing kthread worker API

11th..16th, 18th, 20th patches: convert several kthreads into
      the kthread worker API, namely: khugepaged, ring buffer
      benchmark, hung_task, kmemleak, ipmi, IB/fmr_pool,
      memstick/r592, intel_powerclamp

17th, 19th patches: do some preparation steps; they usually do
      some clean up that makes sense even without the conversion.

Changes against v5:

  + removed spin_trylock() from delayed_kthread_work_timer_fn();
    instead temporary released worked->lock() when calling
    del_timer_sync(); made sure that any queueing was blocked
    by work->canceling in the meatime

  + used 0th byte for KTW_FREEZABLE to reduce confusion

  + fixed warnings in comments reported by make htmldocs
(Continue reading)

Richard W.M. Jones | 13 Apr 21:05 2016
Picon
Gravatar

[PATCH v4 0/3] vfs: Define new syscall umask2 [formerly getumask]

v3 -> v4:

 - Rename the syscall: getumask becomes umask2.

 - Add flags parameter, with one flag (UMASK_GET_MASK).

 - Expand the rationale for this change in the first commit message.

 - Add a selftest.

 - Retest everything.

--------------------

It's not possible to read the process umask without also modifying it,
which is what umask(2) does.  A library cannot read umask safely,
especially if the main program might be multithreaded.

This patch series adds a new system call "umask2".  This adds a flags
parameter.  Specifying flags=UMASK_GET_MASK allows the umask of the
current process to be read without modifying it.

This leaves open the possibility in future of adding a per-thread
umask, set or read with other flags.  This is not implemented.

Another approach to this has been attempted before, adding something
to /proc, although it didn't go anywhere.  See:

  http://comments.gmane.org/gmane.linux.kernel/1292109

(Continue reading)

Richard W.M. Jones | 13 Apr 14:57 2016
Picon
Gravatar

[PATCH v2 0/2] vfs: Define new syscall getumask.

v1 -> v2:

 - Use current_umask() instead of current->fs->umask.

 - Retested it.

----------------------------------------------------------------------

It's not possible to read the process umask without also modifying it,
which is what umask(2) does.  A library cannot read umask safely,
especially if the main program might be multithreaded.

This patch series adds a trivial system call "getumask" which returns
the umask of the current process.

Another approach to this has been attempted before, adding something
to /proc, although it didn't go anywhere.  See:

  http://comments.gmane.org/gmane.linux.kernel/1292109

Another way to solve this would be to add a thread-safe getumask to
glibc.  Since glibc could own the mutex, this would permit libraries
linked to this glibc to read umask safely.

I should also note that man-pages documents getumask(3), but no
version of glibc has ever implemented it.

Typical test script:

#include <stdio.h>
(Continue reading)

Richard W.M. Jones | 13 Apr 13:43 2016
Picon
Gravatar

[PATCH 0/2] vfs: Define new syscall getumask.

It's not possible to read the process umask without also modifying it,
which is what umask(2) does.  A library cannot read umask safely,
especially if the main program might be multithreaded.

This patch series adds a trivial system call "getumask" which returns
the umask of the current process.

Another approach to this has been attempted before, adding something
to /proc, although it didn't go anywhere.  See:

  http://comments.gmane.org/gmane.linux.kernel/1292109

Another way to solve this would be to add a thread-safe getumask to
glibc.  Since glibc could own the mutex, this would permit libraries
linked to this glibc to read umask safely.

I should also note that man-pages documents getumask(3), but no
version of glibc has ever implemented it.

Typical test script:

#include <stdio.h>
#include <stdlib.h>
#include <linux/unistd.h>
#include <sys/syscall.h>

int main(int argc, char *argv[])
{
  int r = syscall(329);
  if (r == -1) {
(Continue reading)


Gmane