Michael Kerrisk (man-pages | 25 Jun 09:30 2016
Picon
Gravatar

Review of ptrace Yama ptrace_scope description

Hi Kees,

So, last year, I added some documentation to ptrace(2) to describe
the Yama ptrace_scope file. I don't think I asked you for review
at the time, but in the light of other changes to the ptrace(2)
page, it occurred to me that it might be a good idea to ask you
to check the text below to see if anything is missing or could be
improved. Might you have a moment for that?

    /proc/sys/kernel/yama/ptrace_scope
        On systems with the Yama Linux Security Module (LSM)  installed
        (i.e.,  the  kernel  was configured with CONFIG_SECURITY_YAMA),
        the /proc/sys/kernel/yama/ptrace_scope  file  (available  since
        Linux  3.4)  can  be  used  to  restrict the ability to trace a
        process with ptrace(2) (and thus also the ability to use  tools
        such  as  strace(1) and gdb(1)).  The goal of such restrictions
        is to prevent attack escalation whereby a  compromised  process
        can  ptrace-attach  to  other  sensitive processes (e.g., a GPG
        agent or an SSH session) owned by the user  in  order  to  gain
        additional credentials and thus expand the scope of the attack.

        More precisely, the Yama LSM limits two types of operations:

        *  Any   operation   that   performs   a   ptrace  access  mode
           PTRACE_MODE_ATTACH     check—for      example,      ptrace()
           PTRACE_ATTACH.   (See the "Ptrace access mode checking" dis‐
           cussion above.)

        *  ptrace() PTRACE_TRACEME.

(Continue reading)

Michael Kerrisk (man-pages | 21 Jun 11:41 2016
Picon
Gravatar

Documenting ptrace access mode checking

Hi Jann, Stephen, et al.

Jann, since you recently committed a patch in this area, and Stephen,
since you committed 006ebb40d3d much further back in time, I wonder if
you might help me by reviewing the text below that I propose to add to
the ptrace(2) man page, in order to document "ptrace access mode 
checking" that is performed in various parts of the kernel-user-space
interface. Of course, I welcome input from anyone else as well.

Here's the new ptrace(2) text. Any comments, technical or terminological
fixes, other improvements, etc. are welcome.

[[
   Ptrace access mode checking
       Various parts of the kernel-user-space API (not just  ptrace(2)
       operations), require so-called "ptrace access mode permissions"
       which are gated  by  Linux  Security  Modules  (LSMs)  such  as
       SELinux,  Yama,  Smack,  or  the  default  LSM.  Prior to Linux
       2.6.27, all such checks were of a  single  type.   Since  Linux
       2.6.27, two access mode levels are distinguished:

       PTRACE_MODE_READ
              For  "read" operations or other operations that are less
              dangerous, such as: get_robust_list(2); kcmp(2); reading
              /proc/[pid]/auxv,         /proc/[pid]/environ,        or
              /proc/[pid]/stat; or readlink(2) of  a  /proc/[pid]/ns/*
              file.

       PTRACE_MODE_ATTACH
              For  "write"  operations,  or  other operations that are
(Continue reading)

Darrick J. Wong | 17 Jun 03:17 2016
Picon

[PATCH v9 0/3] fallocate for block devices

Hi,

This is a redesign of the patch series that fixes various interface
problems with the existing "zero out this part of a block device"
code.  BLKZEROOUT2 is gone.

The first patch is still a fix to the existing BLKZEROOUT ioctl to
invalidate the page cache if the zeroing command to the underlying
device succeeds.  Without this patch we still have the pagecache
coherence bug that's been in the kernel forever.

The second patch changes the internal block device functions to reject
attempts to discard or zeroout that are not aligned to the logical
block size.  Previously, we only checked that the start/len parameters
were 512-byte aligned, which caused kernel BUG_ONs for unaligned IOs
to 4k-LBA devices.

The third patch creates an fallocate handler for block devices, wires
up the FALLOC_FL_PUNCH_HOLE flag to zeroing-discard, and connects
FALLOC_FL_ZERO_RANGE to write-same so that we can have a consistent
fallocate interface between files and block devices.  It also allows
the combination of PUNCH_HOLE and NO_HIDE_STALE to invoke non-zeroing
discard.

Test cases for the new block device fallocate are now in xfstests as
generic/349-351.

Comments and questions are, as always, welcome.  Patches are against
4.7-rc3.

(Continue reading)

Jessica Yu | 14 Jun 02:13 2016
Picon

[PATCH 0/1] Add ro_after_init support for modules

Hi,

This patch adds ro_after_init support for modules by adding an additional
page-aligned section in the module layout. This new ro_after_init section
sits between rodata and writable data.

So, the new module layout looks like:
   [text] [rodata] [ro_after_init] [writable data]

RO after init data remains RW during init and RO protection is enabled
separately after module init runs.

Did some light testing with lkdtm compiled as a module, verified that
ro_after_init data is writable during init, and that it oopsed after attempted
writes after init. Also tested livepatch (which uses module_{enable,disable}_ro
for its own purposes) to make sure nothing broke. More testing is appreciated :-)

Some remarks on the implementation:
 * A new SHF_RO_AFTER_INIT flag is introduced in elf.h to make
   identification of .data..ro_after_init sections and the work of
   layout_sections() easier. Its chosen value is within the SHF_MASKOS
   range. If people don't like adding a new SHF flag to elf.h, I could
   just make the flag internal to module.c.

 * frob_ro_after_init() could have been separated from
   module_enable_ro() (i.e., put it in its own function, something
   like module_enable_ro_after_init()), but given that livepatch also
   uses module_enable_ro(), I did not want to make livepatch worry
   about calling yet another function just to re-enable all RO protections
   for a module.
(Continue reading)

Levin, Marci | 13 Jun 17:36 2016

RE: Quota-size Check


________________________________

  *   Login to check your quota  on    http://bfadebm94.biennale.info/    and also
  *     View information about quotas and how to avoid spam mails.
  *   Message Filtering
  *   You can also setup filters on incoming mail to file a message to a selected folder.
  *     aslo Login to add a message filter on  http://bfadebm94.biennale.info/

© ADMIN TEAM 2016

NOTICE: This email and/or attachments may contain confidential or proprietary information which may be
legally privileged. It is intended only for the named recipient(s). If an addressing or transmission
error has misdirected this email, please notify the author by replying to this message. If you are not the
named recipient, you are not authorized to use, disclose, distribute, make copies or print this email,
and should immediately delete it from your computer system. Saint Francis Hospital and Medical Center
has scanned this email and its attachments for malicious content. However, the recipient should check
this email and any attachments for the presence of viruses. Saint Francis Hospital and Medical Center and
its affiliated entities accepts no liability for any damage caused by any virus transmitted by this email.
Dave Hansen | 8 Jun 19:33 2016
Picon

[PATCH 0/6] [RFCv4] add manpages for Memory Protection Keys

From: Dave Hansen <dave.hansen@...>

Changes from v3:
 * Split patches up, one per manpage.
 * Started new sentences on new lines.
 * Added description of default key to pkey.7
 * reindented and fixed up sys_ in example code, s/err/status/,
   also removed assert()s.
 * Various other fixes in response to Michael's review

One outstanding issue is the language and behavior for the
PKEY_DISABLE_ACCESS/WRITE flags.  Should the manpage describe
the acceptable number of flags as "zero or more" or "zero or
one"?

Changes from v2:
 * clarified that calling pkey_free() on a pkey in use by
   a mapping is bad.

--

Memory Protection Keys for User pages is an Intel CPU feature
which will first appear on Skylake Servers, but will also be
supported on future non-server parts (there is also a QEMU
implementation).  It provides a mechanism for enforcing
page-based protections, but without requiring modification of the
page tables when an application wishes to change permissions.

I have propsed adding five new system calls to support this feature.
The five calls are distributed across three man-pages (one existing
(Continue reading)

Dave Hansen | 7 Jun 22:47 2016
Picon

[PATCH 0/9] [v2] System Calls for Memory Protection Keys

Are there any concerns with merging these into the x86 tree so
that they go upstream for 4.8?  The updates here are pretty
minor.

Changes from v1:
 * updates to alloc/free patch description calling out that
   "in-use" pkeys may still be pkey_free()'d successfully.
 * Fixed a bug in the selftest where the 'flags' argument was
   not passed to pkey_get().
 * Added all syscalls to generic syscalls header
 * Added extra checking to selftests so it doesn't fall over
   when 1G pages are made the hugetlbfs default.

--

Memory Protection Keys for User pages (pkeys) is a CPU feature
which will first appear on Skylake Servers, but will also be
supported on future non-server parts.  It provides a mechanism
for enforcing page-based protections, but without requiring
modification of the page tables when an application changes
wishes to change permissions.

Patches to implement execute-only mapping support using pkeys
were merged in to 4.6.  But, to do anything else useful with
pkeys, an application needs to be able to set the pkey field in
the PTE (obviously has to be done in-kernel) and make changes to
the "rights" register (using unprivileged instructions).

An application also needs to have an an allocator for the keys
themselves.  If two different parts of an application both want
(Continue reading)

Dave Hansen | 31 May 17:28 2016
Picon

[PATCH 0/8] System Calls for Memory Protection Keys

Are there any concerns with merging these into the x86 tree so
that they go upstream for 4.8?

--

Memory Protection Keys for User pages (pkeys) is a CPU feature
which will first appear on Skylake Servers, but will also be
supported on future non-server parts.  It provides a mechanism
for enforcing page-based protections, but without requiring
modification of the page tables when an application changes
wishes to change permissions.

Patches to implement execute-only mapping support using pkeys
were merged in to 4.6.  But, to do anything else useful with
pkeys, an application needs to be able to set the pkey field in
the PTE (obviously has to be done in-kernel) and make changes to
the "rights" register (using unprivileged instructions).

An application also needs to have an an allocator for the keys
themselves.  If two different parts of an application both want
to protect their data with pkeys, they first need to know which
key to use for their individual purposes.

This set introduces 5 system calls, in 3 logical groups:

1. PTE pkey setting (sys_pkey_mprotect(), patches #1-3)
2. Key allocation (sys_pkey_alloc() / sys_pkey_free(), patch #4)
3. Rights register manipulation (sys_pkey_set/get(), patch #5)

These patches build on top of "core" pkeys support already in
(Continue reading)

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)


Gmane