Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Sat, 23 Apr 2011 18:25:37 +0400
From: Vasiliy Kulikov <>
To:, Eugene Teo <>
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.

	"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).

	"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.


    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.

	"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.


    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.

	"Deny writing to /dev/kmem, /dev/mem, and /dev/port"
	"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.

(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

	"Remove addresses from /proc/<pid>/[smaps|maps|stat]"
	"Hide kernel symbols"
	"Additional restrictions"
"...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.


    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.


    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.


    These are redundant with namespaces and containers.  If you want to
    restrict what the program may do, run it in the container.

"...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.


    Already in mainline and Owl.


    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.

(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.


    These option may be a subset of more generic socket restrictions.  I
    think about such scheme: introduce cgroup family with a single options:


    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

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: - ow patch features description, - grsecurity patch

Vasiliy Kulikov - 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.