On Fri, Mar 17, 2023 at 12:42 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > On Fri, Mar 17, 2023 at 8:26 AM Stephen Smalley > <stephen.smalley.work@xxxxxxxxx> wrote: > > On Thu, Mar 16, 2023 at 4:34 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > > > > > We originally promised that the SELinux 'checkreqprot' functionality > > > would be removed no sooner than June 2021, and now that it is March > > > 2023 it seems like it is a good time to do the final removal. The > > > deprecation notice in the kernel provides plenty of detail on why > > > 'checkreqprot' is not desirable, with the key point repeated below: > > > > > > This was a compatibility mechanism for legacy userspace and > > > for the READ_IMPLIES_EXEC personality flag. However, if set to > > > 1, it weakens security by allowing mappings to be made executable > > > without authorization by policy. The default value of checkreqprot > > > at boot was changed starting in Linux v4.4 to 0 (i.e. check the > > > actual protection), and Android and Linux distributions have been > > > explicitly writing a "0" to /sys/fs/selinux/checkreqprot during > > > initialization for some time. > > > > > > Along with the official deprecation notice, we have been discussing > > > this on-list and directly with several of the larger SELinux-based > > > distros and everyone is happy to see this feature finally removed. > > > In an attempt to catch all of the smaller, and DIY, Linux systems > > > we have been writing a deprecation notice URL into the kernel log, > > > along with a growing ssleep() penalty, when admins enabled > > > checkreqprot at runtime or via the kernel command line. We have > > > yet to have anyone come to us and raise an objection to the > > > deprecation or planned removal. > > > > > > It is worth noting that while this patch removes the checkreqprot > > > functionality, it leaves the user visible interfaces (kernel command > > > line and selinuxfs file) intact, just inert. This should help > > > prevent breakages with existing userspace tools that correctly, but > > > unnecessarily, disable checkreqprot at boot or runtime. Admins > > > that attempt to enable checkreqprot will be met with a removal > > > message in the kernel log. > > > > > > Signed-off-by: Paul Moore <paul@xxxxxxxxxxxxxx> > > > > Acked-by: Stephen Smalley <stephen.smalley.work@xxxxxxxxx> > > Thanks Stephen. I'm going to hold off on merging this into > selinux/next until Monday, partially to give people some additional > time to comment/object, and partially because I don't want to blow up > anyone's system over the weekend ;) I just merged this into selinux/next. -- paul-moore.com
