grsecurity forums

what features would you like to see in new versions of grsecurity? post them here. Here's some things we have already planned:

native encrypted swap support (just like openbsd)
per-binary passwords for the authentication system
auto-generated acls

i'm also thinking of writing some kind of web-based admin tool focusing more on keeping watch and taking control over your users

I'm working on time support for acls like in LIDS, as well as improved documentation(anyone interested in writing docs please contact me), and inheritance levels.

spender wrote:what features would you like to see in new versions of grsecurity? post them here. Here's some things we have already planned:

i would like to see sth like BIND_ONCE to allow a daemon to bind
to the port only once

AFAIK there is sth similar in in LIDS

This might be a little bit far off, but I'm wondering if you have any plans porting grsecurity to other platforms. OpenBSD for instance.

I had considered porting the ACL system at one time. Its a little far off, but yeah its probably doable. It'd be a nasty job, but there's nothing specifically tieing us to linux.

does it really need such a thing to improve system security?
which parts of grsec aren't present in OpenBSD, and which aren't present in TrustedBSD??

there's many things that aren't present in openbsd. Really the only things that are present in bsd are some of the chroot stuff (via its jail interface) and the randomized options. There's still plenty more features of grsecurity to port.

TrustedBSD uses POSIX .1e ACLS, which are limited, fs-specific ACLs, as well as Biba/MLS acl models. Our acl system is more robust than Biba/MLS, which are more suited
to certain military situations (hmm..DARPA funding for
TrustedBSD and military situation-friendly ACLs..surprise:).
If requested we can support the classification of files
by "integrity" like Biba does with relative ease, as well
as possessing our file / program acl checks and capability
management. We also have a fs-independant ACL system,
unlike POSIX .1e ACLs, so our portability is superior. FreeBSD
has LOMAC committed, something by the TrustedBSD guy that
divides the system into trusted and untrusted files. I don't
think I need to compare that to grsecurity's acl system,
although I will concede that it is most likely easier to
configure due to its simpler nature. Hope this helped

Michael

It would be great to have the various log features ported to OpenBSD. The CONFIG_GRKERNSEC_EXECLOG - for instance - would be great to have on servers with shell users present.

You're doing a great job!

one of the biggest problems i encounter with my web hosting service - is problems with fork bombs or other attacks targeted to consume resources.

PAM Resource limiting is good but it lacks some features (e.g: logging). To that effect i also encounter users trying to run scripts via apache (php, perl and other types of scripts) that attempt to consume resources. This is not something that occurs all the time but when it does it is offten a a painfull task in tracking offending users (lack of logging ?) and more so preventing such attacks.

So i think it would be very nice if grsecurity provided some type of resource limiting of some type or something similar. Perhaps there is already such features in the works and i just dont know

grsecurity already provides fork bomb protection. Have a look through the "features" page.

One suggestion a friend of mine was interested in was getting killed processes (by PaX/Openwall) to, instead of just logging the EIP and the data there, drop a core dump, so if someone was so inclined they could see _exactly_ what the user was trying to do at the time.

something like that would get too yucky. There's reasons why sometimes you don't want to coredump. One of them is that you don't want files left around that contain sensitive information. fork bomb protection is removed in 1.9.5, as there's many other ways to raise huge loads on a server, and you can handle limiting the number of processes in PAM in a more fine-grained way.

-Brad

you mean a fork bomb feature... yes i know its their and have used it - it doesnt do me much good. If a user writes a perl script to exectue itself 10,000 times and runs it via apache - the fork bomb features of grsecurity prove uselss (of cource).

What im saying is grsecurity needs more features surounding restrictions on resources - i dont know if this is somthing to be considered for the ACL system or the core grsec path.

Could we get MD5 sums on selected sensitive binaries (suid/sgid f.ex.)
that were checked against a central db before execution?

That way we could get rid of trojans and rootkits alike... Seen it done
in a couple of firewalls on Win.

-blue