-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I've looked at PaX and GrSecurity a lot, and briefly touched RSBAC. Now
I have a simple, but profound question. (keep Ingo Molnar and Linus
Torvalds away from here if you don't want to see a holy war)
How much *!@# can I implement with SELinux?
I'd figure, I could do some crazy stuff like teach it to mimic
grsecurity's linking restrictions, say:
====
Hardlinks to files not owned by the current user cannot be created
without CAP_FOWNER:
- If a hardlink is to be created
+ and the target file is owned by the current user
* creation of the hardlink is not disallowed
+ and the target file is not owned by the current user
= and capability CAP_FOWNER is granted
* creation of the hardlink is not disallowed
= and capability CAP_FOWNER is not granted
* creation of the hardlink is disallowed
Symbolic links in directories with the sticky bit and write permission
for "others" cannot be followed unless they are labeled with type
t_follow_symlink:
- If a symlink is to be followed
+ and it is not in a sticky directory
= following of the symlink is not disallowed
+ and it is in a sticky directory
= and it is not in a directory writable by "others"
* following of the symlink is not disallowed
= and it is in a directory writable by "others"
* and it is labeled with type t_follow_symlink
% following of the symlink is not disallowed
* and it is not labeled with type t_follow_symlink
% following of the symlink is disallowed
====
Of course the above would have to be turned into a fragment of SELinux
policy, but would it work? Probably.
I'm thinking, you may be able to mimic PaX mprotect() restrictions (a
specific memory protection policy to separate data and code strictly),
GrSecurity /proc restrictions, linking restrictions, access to
/dev/{k,}mem, privileged IO, and a bunch of other stuff with SELinux
policy. Other things need to go right into kernel.
The /dev/kmem restrictions in GrSecurity allow for /dev/kmem to be
accessed for video memory ONLY; this requires some kernel code to
duplicate, rather than pure policy. Of course, once that code is
written, it can be hooked into by LSM; thus, a policy to constrict
things down and still let X work would be possible.
Address space layout randomization in the kernel is minimal and weak.
(if Ingo, Arjan, or Linus see this, there's going to be a holy war.)
It's basically no heap randomization, 12 bits on libraries and mmap(),
and around 20 bits for the stack. The stack is randomized back and
forth in a 64KiB area which will later become a 2MiB area; a relatively
short NOP slide (CERT) or NOP sled (Erickson) or whatever you want to
call it will turn that 20 bits into 5 or 10.
For address space layout randomization to be stronger, kernel-side code
would have to be written to supply the PaX-esque 256MiB range of
randomization for the stack, as well as heap randomization, and
potentially better mmap() randomization. Then hooks would have to be
added for LSM to force the minimum randomization quality for each part
(i.e. 0, 64KiB, 2MiB, or 256MiB for stack). The logic here is that the
program might want to run with 256MiB stack randomization and SELinux
says it needs to run with at least 2MiB stack randomization, so it gets
its 256MiB; but if it wants to run with 0MiB of stack randomization
range, it will be forced to run with 2MiB. Obviously it's typically
going to run with 0MiB by default, and the policy would say, "Hey! Up
the randomization!"
(note with the size of randomization, it'd be rather architecture
specific. Athlon/PPC/Sparc 64 machines can take advantage of a huge VM
space and use much bigger randomization ranges)
Another thing written in the kernel would be a hook to control fork()
and implement complex brute force deterrence similar to what GrSecurity
supplies. Due to its complexity (it's actually a set of defined logic
that operates under conditions that have passed instead of just
immediate conditions), this may need to be fully written in kernel code
and hooked by LSM for use in SELinux.
So, pretty much, I'm wondering how much of GrSecurity and PaX can be
mimicked in a policy, and how much will need some solid kernel coding.
I don't know how to write SELinux policies unfortunately, or I'd
probably be able to answer my own question.
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDOONehDd4aOud5P8RAmzLAJsE7IiLQHCcPpC+7PjN+12D+MVd+QCeO0oU
mECZYt7qVxZQC2TKgmNS5Wg=
=rzRk
-----END PGP SIGNATURE-----
This archive was generated by hypermail 2.1.3 : Mon Sep 26 2005 - 23:16:34 PDT