site
contact
newsKernel 5.10 lockdown success
This morning I posted about patching the 5.4.83 kernel with my
CAP_SYS_MOUNT patch and testing in EasyOS lockdown mode, but Xorg failed
to run:
https://bkhome.org/news/202012/intending-to-move-to-510-lts-kernel.html
So, have compiled the 5.10-rc7 kernel. Thanks to Puppy Forum member 'peebee' who has posted aufs5 patches for the 5.10 kernel:
https://sourceforge.net/projects/lxpup/files/Other/huge-kernels/kernel-5.10-aufs-changes/
https://forum.puppylinux.com/viewtopic.php?f=65&p=11678&i=1
I reworked the CAP_SYS_MOUNT patch for the 5.10 kernel, and built
EasyOS version 2.5.3.2, booted it, then chose to reboot in "Copy session
to RAM and disable drives" mode -- yes, have a desktop!
The situation is the CAP_SYS_ADMIN Linux Capability is disabled, but
can still replug the USB-stick and save to it. CAP_SYS_ADMIN is a whole
swag of root-only permissions that we don't need in lockdown, or rather,
we don't seem to need them...
/var/log/Xorg.0.log has this in it:
[ 50.957] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[ 50.957] (II) FBDEV: driver for framebuffer: fbdev
[ 50.957] (II) VESA: driver for VESA chipsets: vesa
[ 50.968] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted)
[ 50.983] (II) modeset(0): using drv /dev/dri/card0
...Xorg modesetting driver is now working, but seems have an error when it tried to test vesa driver. This is a non-fatal error.
And in file /tmp/bootsysinit.log, have these errors:
MISC. SYSTEM SETUP
hostname: sethostname: Operation not permitted
USER SELECTED MODULES
SETUP SERVICES
rc.sysinit: Setting up services (network, printing, etc.)...
rc.sysinit: modem
Cannot set serial info: Operation not permitted
rc.sysinit: battery, ac, thermal, fan modules
...again, non-fatal, and everything seems to be working. Was able to
save session to USB-stick, connect to Internet via wifi, play music.
I might as well post the CAP_SYS_MOUNT patch for the 5.10 kernel, in
case anyone is interested. It is in two parts. Firstly, file
'cap_sys_mount-1.patch':
diff -Naur linux-5.10/include/uapi/linux/capability.h linux-5.10P1/include/uapi/linux/capability.h
--- linux-5.10/include/uapi/linux/capability.h 2020-12-07 06:25:12.000000000 +0800
+++ linux-5.10P1/include/uapi/linux/capability.h 2020-12-14 11:03:39.127180439 +0800
@@ -417,7 +417,9 @@
#define CAP_CHECKPOINT_RESTORE 40
-#define CAP_LAST_CAP CAP_CHECKPOINT_RESTORE
+#define CAP_SYS_MOUNT 41
+
+#define CAP_LAST_CAP CAP_SYS_MOUNT
#define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
diff -Naur linux-5.10/security/selinux/include/classmap.h linux-5.10P1/security/selinux/include/classmap.h
--- linux-5.10/security/selinux/include/classmap.h 2020-12-07 06:25:12.000000000 +0800
+++ linux-5.10P1/security/selinux/include/classmap.h 2020-12-14 11:09:33.393857376 +0800
@@ -28,9 +28,9 @@
#define COMMON_CAP2_PERMS "mac_override", "mac_admin", "syslog", \
"wake_alarm", "block_suspend", "audit_read", "perfmon", "bpf", \
- "checkpoint_restore"
+ "checkpoint_restore", "sys_mount"
-#if CAP_LAST_CAP > CAP_CHECKPOINT_RESTORE
+#if CAP_LAST_CAP > CAP_SYS_MOUNT
#error New capability defined, please update COMMON_CAP2_PERMS.
#endif
And file 'cap_sys_mount-2.patch':
diff -Naur linux-5.10P1/fs/cachefiles/daemon.c linux-5.10P2/fs/cachefiles/daemon.c
--- linux-5.10P1/fs/cachefiles/daemon.c 2020-12-07 06:25:12.000000000 +0800
+++ linux-5.10P2/fs/cachefiles/daemon.c 2020-12-14 11:22:48.633880384 +0800
@@ -87,7 +87,7 @@
_enter("");
/* only the superuser may do this */
- if (!capable(CAP_SYS_ADMIN))
+ if (!capable(CAP_SYS_MOUNT))
return -EPERM;
/* the cachefiles device may only be open once at a time */
diff -Naur linux-5.10P1/fs/ext4/ioctl.c linux-5.10P2/fs/ext4/ioctl.c
--- linux-5.10P1/fs/ext4/ioctl.c 2020-12-07 06:25:12.000000000 +0800
+++ linux-5.10P2/fs/ext4/ioctl.c 2020-12-14 11:25:08.440551087 +0800
@@ -605,7 +605,7 @@
struct ext4_sb_info *sbi = EXT4_SB(sb);
__u32 flags;
- if (!capable(CAP_SYS_ADMIN))
+ if (!capable(CAP_SYS_MOUNT))
return -EPERM;
if (get_user(flags, (__u32 __user *)arg))
diff -Naur linux-5.10P1/fs/namespace.c linux-5.10P2/fs/namespace.c
--- linux-5.10P1/fs/namespace.c 2020-12-07 06:25:12.000000000 +0800
+++ linux-5.10P2/fs/namespace.c 2020-12-14 11:27:05.200554488 +0800
@@ -1690,7 +1690,7 @@
*/
static inline bool may_mount(void)
{
- return ns_capable(current->nsproxy->mnt_ns->user_ns, CAP_SYS_ADMIN);
+ return ns_capable(current->nsproxy->mnt_ns->user_ns, CAP_SYS_MOUNT);
}
#ifdef CONFIG_MANDATORY_FILE_LOCKING
diff -Naur linux-5.10P1/fs/super.c linux-5.10P2/fs/super.c
--- linux-5.10P1/fs/super.c 2020-12-07 06:25:12.000000000 +0800
+++ linux-5.10P2/fs/super.c 2020-12-14 11:28:35.303890430 +0800
@@ -485,9 +485,9 @@
bool mount_capable(struct fs_context *fc)
{
if (!(fc->fs_type->fs_flags & FS_USERNS_MOUNT))
- return capable(CAP_SYS_ADMIN);
+ return capable(CAP_SYS_MOUNT);
else
- return ns_capable(fc->user_ns, CAP_SYS_ADMIN);
+ return ns_capable(fc->user_ns, CAP_SYS_MOUNT);
}
/**
These derive from original patches created in 2017, by Nicolas Belouin:
https://www.spinics.net/lists/selinux/msg23373.html
...if I recall rightly, Nicolas separated CAP_SYS_MOUNT, but also
kept CAP_SYS_ADMIN original functionality. So if CAP_SYS_ADMIN is
dropped, so too would the ability to mount and unmount -- not what I
want.
A final technical note: I have patched the 'capsh' utility to
recognise "cap_sys_mount". An un-patched 'capsh' can still access it, by
its number, "41".
A note for end-users, who might be reading this and wondering what it
all means: The objective is to lockdown "Copy session to RAM &
disable drives" even more, aiming for ever-tighter security, without
affecting normal user functionality. So it should not be something that
you notice as a user, but you have greater assurance of security.
As CAP_SYS_ADMIN has been dropped in the initrd, before switching to
the main filesystem, there is no way that an intruder can bump up to
full root administrator rights -- unlike a normal Linux distribution,
where full-power root is there and can be targeted by the intruder.
Tags: easy