Date: Sat, 23 Apr 2011 18:25:37 +0400 From: Vasiliy Kulikov <segoon@...nwall.com> To: owl-dev@...ts.openwall.com, Eugene Teo <eugene@...hat.com> Subject: GSoC: overview of grsecurity and -ow patches Solar, Eugene, all - I'm trying to figure out what grsecurity and -ow features we need for the mainline and RHEL6/OpenVZ kernels. Some options are too grsecurity specific, some of them are obsoleted in sense of namespaces. I did some research, here are my thoughts. I didn't sort them in any way, the order is almost arbitrary. GRKERNSEC_VM86 [+] "Restrict VM86 mode" We need it, but IMO it's better to restrict it to some group and make binaries that need VM86 mode sgid to this group (grsecurity restricts it to CAP_RAW_IO). GRKERNSEC_MODHARDEN [+] "Harden module auto-loading" Dan Rosenberg tried to push it into mainline, but it's not there yet. It worth trying to push it again. https://lkml.org/lkml/2010/11/7/212 GRKERNSEC_LINK [+] GRKERNSEC_FIFO [+] GRKERNSEC_HARDEN_PTRACE [+] There is YAMA LSM for mainline, implementing these features. It is not yet applied, but Kees Cook does his best to push it. For RHEL6/OpenVZ YAMA should be OK (with Ubuntu's forcing scheme), with minor synchorization changes. GRKERNSEC_EXECVE [+] "Enforce RLIMIT_NPROC on execs" Obvious option, we need it. RBAC* [-] We don't need any MAC for RHEL6/OpenVZ. There are already other MACs in the mainline, and nobody would gain any benefit with RBAC introduction if it is only yet-another-MAC. GRKERNSEC_PROC [+] GRKERNSEC_SYSFS_RESTRICT [+] Both procfs and sysfs need "umask" and "gid" options to restrict pid directories to the process owner, and network related information to some group. Currently procfs gets mount option only from kernel mounters and interprets it as a pointer to the struct pid_namespace. sysfs ignores options. GRKERNSEC_KMEM [-] "Deny writing to /dev/kmem, /dev/mem, and /dev/port" GRKERNSEC_IO [-] "Disable privileged I/O" These look like a securelevel, which is not native in Linux. /dev/kmem is already configurable via CONFIG_DEVKMEM. X Server wants ioperm anyway, and they are already limited in containers. GRKERNSEC_ROFS [-] (disable remounting read-only mount points.) It smells like introducing securelevels. I don't think that the option would improve the security as such securelevel is not yet consistent. GRKERNSEC_PROC_MEMMAP [+] "Remove addresses from /proc/<pid>/[smaps|maps|stat]" GRKERNSEC_HIDESYM [+] "Hide kernel symbols" GRKERNSEC_PROC_ADD [+] "Additional restrictions" GRKERNSEC_RANDNET [+] "...the entropy pools used for many features of Linux and grsecurity will be doubled in size." All these options are neaty, but only after kernel ASLR introducing. Also it worth saying that the whole sysfs subsystem needs a review for a kernel addresses leakage. GRKERNSEC_BRUTE [-] GRKERNSEC_KERN_LOCKOUT [-] These options make the parent of a killed by a SIGSEGV process sleeping for 30 secs, and kill all processes owned by an owner of a process trying to exploit the kernel with a ban, respectively. I'm not sure whether these are appropriate either for Owl or for mainline. They are too limited and only slow down remote ASLR breakage. GRKERNSEC_ACL_HIDEKERN [+] It hides kernel threads, configurable via RBAC. Maybe a variation of this is needed, sysctl'able global (not per-container) variable - if set to 1 then restrict the information to HN's root. GRKERNSEC_CHROOT* [-] These are redundant with namespaces and containers. If you want to restrict what the program may do, run it in the container. GRKERNSEC_AUDIT* [-] GRKERNSEC_PROC_IPADDR [-] "...a new entry will be added to each /proc/<pid> directory that contains the IP address of the person using the task." IMO it is redundant for mainline - there is also audit framework with more generic and runtime configurable behaviour. GRKERNSEC_DMESG Already in mainline and Owl. GRKERNSEC_TPE* [-] I don't think it is a significant improvement over classic execution policy. It is broken by any arbitrary code execution and only prevents from "occasional" arbitrary binary execution. However, it is already included into OpenVZ. GRKERNSEC_BLACKHOLE [+] (don't answer with TCP RST and ICMP port unreachable for closed ports) Its usefullness is a bit limited, but it looks harmless. It can be implemented per net namespaces. GRKERNSEC_SOCKET GRKERNSEC_SOCKET_SERVER These option may be a subset of more generic socket restrictions. I think about such scheme: introduce cgroup family with a single options: socket.allowed with lines in format "domain type protocol usage", where domain, type, and protocol are integer, and usage is a string of "s" (socket(2)), "c" (connect(2)), "l" (listen(2)). It behaves like device cgroup, restricting cdev and bdev creation/usage to the whitelist. It makes possible to restrict containers to IPv4 or IPv6 only, deny (relatively) rare protocols like SCTP or DCCP. For mainline kernel it makes sense to implement similar cgroup for filesystem types. There is already a strict set of filesystems allowed in containers (procfs, sysfs, and ext*), loop devices are disabled by default. As for -ow patch: (...skipping features merged into grsecurity...) Fd 0/1/2 reopening if closed [-] As it is already introduced in glibc, it makes sense only together with old glibc/alternative libc library. Destroy shared memory not in use [+] We need it, configurable per pid namespace. Privileged aliases [-] I think it is fully obsoleted with introducing network namespaces. I haven't carefully studied PaX features yet (userspace/kernel ASLR, nonexecutable and RO segments, "sticky" RO segments, with configurable exceptions, refcount overflow prevention, etc.), I'll refer to them a bit later. References: http://www.openwall.com/linux/README.shtml - ow patch features description http://grsecurity.net/features.php, http://grsecurity.net/download.php - grsecurity patch -- Vasiliy Kulikov http://www.openwall.com - bringing security into open computing environments Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.