Re: ANN: SELinux userspace release 20170804 / 2.7
On Fri, Aug 04, 2017 at 02:57:20PM -0400, Stephen Smalley wrote: > The 20170804 / 2.7 release for the SELinux userspace release is now > available from: > https://github.com/SELinuxProject/selinux/wiki/Releases Thanks for bringing us this new release! > > Below are some notes on this release for packagers and users of the > SELinux userspace. git log and git shortlog output for all changes > since the 20161014 / 2.6 release are linked from the release page. > Thanks to all the contributors to this release! > > If you notice corrections or additional items that should be added to > the release notes (below and also linked from the releases page), reply > to this message with your suggested changes/additions and we'll add > them to the one linked from the releases page too. > > * This is the first release with the split up policycoreutils (see > https://www.mail-archive.com/selinux@tycho.nsa.gov/msg02914.html and > the rest of that thread). Fedora already packages many of these > components separately, although not always with the same organization > and naming scheme. Note that a number of these components are not > necessary for basic use of SELinux and likely should not be installed > by default, e.g. selinux-dbus, selinux-gui, mcstrans, restorecond, > selinux-sandbox. > > * libsepol now has binary module support for ioctl xperms rules > (module version 18), making it possible to use allowxperm rules in > modularly built refpolicy-based policies. Previously, ioctl xperms > rules were only supported in monolithic policy and in CIL modules. > This change means that refpolicy and/or policies derived from it can > begin to leverage ioctl whitelisting, which has already been leveraged > for some time in Android policies, which do not rely on binary modules. > > * This release introduces support for Infiniband object labeling, > including support for kernel policy version 31 and module version 19, > policy.conf and CIL language support, and semanage support. The > corresponding kernel support was introduced in Linux v4.13. > > * This release introduces support for building policies with the > extended_socket_class, cgroup_seclabel, and nnp_nosuid_transition > policy > capabilities enabled: > > ** The extended_socket_class policy capability allows distinctions to > be made in policy among socket address families that were previously > mapped to the generic socket class (e.g. bluetooth, nfc, and many > other socket address families that previously did not have their own > distinct security class) as well as for SCTP and ICMP/ping sockets > that were previously mapped to the rawip_socket class. This policy > capability is supported by Linux v4.11 and later. Enabling this > capability > in policy requires reviewing existing rules on socket and rawip_socket > classes to determine whether they should be duplicated for the new > classes. > > ** The cgroup_seclabel policy capability allows userspace to set > labels on cgroup/cgroup2 files, enabling fine-grained labeling of > cgroup files by userspace. This policy capability is also supported > by Linux v4.11 and later. Note that enabling this capability will > break current Android userspace/policy and requires introducing > appropriate file_contexts definitions for cgroup files (or a change to > the Android init program's handling of them) in order to avoid > mislabeling them. > > ** The nnp_nosuid_transition policy capability enables SELinux domain > transitions to occur under no_new_privs (NNP) or on nosuid mounts if > the corresponding permission (nnp_transition for NNP, > nosuid_transition for nosuid; both in the newly defined process2 > security class / access vector) is allowed between the old and new > contexts. This change was motivated by the increasing use of NNP by > systemd for confining system services and the desire to be able to > leverage NNP/nosuid-provided protections in combination with SELinux > rather than having to make undesirable tradeoffs in security. With > this policy capability enabled and the corresponding permissions > allowed where required, it should be possible to use upstream systemd > unit files without modification on SELinux-enabled systems. > NB: Allowing nnp_transition between two contexts opens up the > potential for the old context to subvert the new context by > installing seccomp filters before the execve. Allowing > nosuid_transition between two contexts opens up the potential for > a context transition to occur on a file from an untrusted > filesystem (e.g. removable media or remote filesystem). Use with > care. Linux support is expected with 4.14 > > * checkpolicy now supports generating CIL or policy.conf from a > kernel binary po
ANN: SELinux userspace release 20170804 / 2.7
The 20170804 / 2.7 release for the SELinux userspace release is now available from: https://github.com/SELinuxProject/selinux/wiki/Releases Below are some notes on this release for packagers and users of the SELinux userspace. git log and git shortlog output for all changes since the 20161014 / 2.6 release are linked from the release page. Thanks to all the contributors to this release! If you notice corrections or additional items that should be added to the release notes (below and also linked from the releases page), reply to this message with your suggested changes/additions and we'll add them to the one linked from the releases page too. * This is the first release with the split up policycoreutils (see https://www.mail-archive.com/selinux@tycho.nsa.gov/msg02914.html and the rest of that thread). Fedora already packages many of these components separately, although not always with the same organization and naming scheme. Note that a number of these components are not necessary for basic use of SELinux and likely should not be installed by default, e.g. selinux-dbus, selinux-gui, mcstrans, restorecond, selinux-sandbox. * libsepol now has binary module support for ioctl xperms rules (module version 18), making it possible to use allowxperm rules in modularly built refpolicy-based policies. Previously, ioctl xperms rules were only supported in monolithic policy and in CIL modules. This change means that refpolicy and/or policies derived from it can begin to leverage ioctl whitelisting, which has already been leveraged for some time in Android policies, which do not rely on binary modules. * This release introduces support for Infiniband object labeling, including support for kernel policy version 31 and module version 19, policy.conf and CIL language support, and semanage support. The corresponding kernel support was introduced in Linux v4.13. * This release introduces support for building policies with the extended_socket_class, cgroup_seclabel, and nnp_nosuid_transition policy capabilities enabled: ** The extended_socket_class policy capability allows distinctions to be made in policy among socket address families that were previously mapped to the generic socket class (e.g. bluetooth, nfc, and many other socket address families that previously did not have their own distinct security class) as well as for SCTP and ICMP/ping sockets that were previously mapped to the rawip_socket class. This policy capability is supported by Linux v4.11 and later. Enabling this capability in policy requires reviewing existing rules on socket and rawip_socket classes to determine whether they should be duplicated for the new classes. ** The cgroup_seclabel policy capability allows userspace to set labels on cgroup/cgroup2 files, enabling fine-grained labeling of cgroup files by userspace. This policy capability is also supported by Linux v4.11 and later. Note that enabling this capability will break current Android userspace/policy and requires introducing appropriate file_contexts definitions for cgroup files (or a change to the Android init program's handling of them) in order to avoid mislabeling them. ** The nnp_nosuid_transition policy capability enables SELinux domain transitions to occur under no_new_privs (NNP) or on nosuid mounts if the corresponding permission (nnp_transition for NNP, nosuid_transition for nosuid; both in the newly defined process2 security class / access vector) is allowed between the old and new contexts. This change was motivated by the increasing use of NNP by systemd for confining system services and the desire to be able to leverage NNP/nosuid-provided protections in combination with SELinux rather than having to make undesirable tradeoffs in security. With this policy capability enabled and the corresponding permissions allowed where required, it should be possible to use upstream systemd unit files without modification on SELinux-enabled systems. NB: Allowing nnp_transition between two contexts opens up the potential for the old context to subvert the new context by installing seccomp filters before the execve. Allowing nosuid_transition between two contexts opens up the potential for a context transition to occur on a file from an untrusted filesystem (e.g. removable media or remote filesystem). Use with care. * checkpolicy now supports generating CIL or policy.conf from a kernel binary policy. Sample usage is checkpolicy -M -C -b policy.N -o policy.cil and checkpolicy -M -F -b policy.N -o policy.conf. There is also now a secil2conf program that can generate policy.conf from CIL, e.g. secil2conf -o policy.conf policy.cil. * Attribute generation and expansion has changed in several ways in order to address kernel runtime performance issues that occur when types have many attributes assigned to them while ensuring preservation of attributes where desired. Binary module to CIL conversion now ensures that duplicate attributes are not generated for the
Re: suspicious __GFP_NOMEMALLOC in selinux
On Fri, Aug 4, 2017 at 3:56 AM, Michal Hocko wrote: > On Thu 03-08-17 14:17:26, Paul Moore wrote: >> On Thu, Aug 3, 2017 at 7:05 AM, Michal Hocko wrote: >> > On Thu 03-08-17 19:44:46, Tetsuo Handa wrote: > [...] >> >> When allocating thread is selected as an OOM victim, it gets TIF_MEMDIE. >> >> Since that function might be called from !in_interrupt() context, it is >> >> possible that gfp_pfmemalloc_allowed() returns true due to TIF_MEMDIE and >> >> the OOM victim will dip into memory reserves even when allocation failure >> >> is not a problem. >> > >> > Yes this is possible but I do not see any major problem with that. >> > I wouldn't add __GFP_NOMEMALLOC unless there is a real runaway of some >> > sort that could be abused. >> >> Adding __GFP_NOMEMALLOC would not hurt anything would it? > > I is not harmfull but I fail to see how it would be useful either and as > such it just adds a pointless gfp flag and confusion to whoever tries to > modify the code in future. Really the main purpose of __GFP_NOMEMALLOC > is to override the process scope PF_MEMALLOC. As such it is quite a hack > and the fewer users we have the better. Okay, that is a viable explanation for me. > Btw. Should I resend the patch or somebody will take it from this email > thread? No, unless your mailer mangled the patch I should be able to pull it from this thread. However, I'm probably going to let this sit until early next week on the odd chance that anyone else wants to comment on the flag choice. I'll send another reply once I merge the patch. -- paul moore www.paul-moore.com
