[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110423142537.GA9838@albatros>
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.
