taking feature requests

[Sharky]

I would love to see an option in the next coming grsecurity versions that allows the built of chroot jails. you seet he way untrusted GID works? user can not Execute any file ? i would like something similiar to that however the user would BE locked in his home Directory with very few basic utilities he can use such as cd,ls,mkdir,rm etc... would do u think of that?

[Technion]

There are already hundreds of projects out there involving chroots.
grsecurity is a kernel based system.... whilst you are clearly referring to some type of shell of application. Why do you see the need for yet another chroot based security enhancement, in the kernel of all places?

Most likely what you are interested in is the chroot patches for OpenSSH.

But grsecurity has an ACL set for a reason. Try reading about how it works.

It also has TPE. Isn't that basically what you are asking for when you say "user can not Execute any file ?"

Finally, I question the usefulness of such a system. What are users doing?
Running a website? Why not force them to use an ftp daemon that chroots itself to a user's home directory upon login? That would kill the problem with an existing system, and probably more securely.
Any sort of development? They then need access to /usr/lib to compile anything.. your system breaks.
Email? Ever heard of POP3 without allowing shells?

Lastly, bash has a restricted shell option. Read its manpage. That may also be useful to you.

In fact I can't envisage an actual purpose to a system I could SSH into where my only abilities were cd, ls, mkdir and rm as you suggest, where there isn't a better way to accomplish it.

[Sharky]

hey Technion

well i did not say that the only commands they would need is cd and ls.
i said variety, and the need for such a jail root system is for users who must gain aCESSS on the SERVER for shell providing such as psybnc's/bnc/eggdrops. I did already build a kind of chroot sys with the help of Spender yesterday, I hope my point was clear.

[jMh]

I for one would like to see syslog-ng support

[SoulBlazer]

The ability to control what log level grsec outputs kernel messages too, and the ability to send syslog(2) messages directly via the kernel to a remote host without the need to rely on a syslog daemon (I believe lids does this?).

Additionally the another GID that behaves like the Kernel Auditing GID system only for chroot logging. As it is any chroot I create prints kernel messages depending on what logging options I have enabled, I would very much like to limit this to only a specific GID I can tag accounts with.

Cheers,

[TGKx]

Sorry to make big issues of small points, but wouldnt it make more sense to use SHA1 sums rather than md5's because of security (uniqueness) and performance issues?

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

[kig]

Hi, a couple of ideas I had in mind after reading the grsecurity acl doc. Hopefully these aren't really stupid, already implemented or argued to death

Would it be within the scope of grsecurity to apply process-level i/o bandwidth throttling? In particular, network interfaces and disk bandwidth. Or is this better left to, say, ip firewalls? And on the subject of throttling, could there be a percentage-based res_cpu or is it technologically infeasible to implement on kernel level?

The other thing I had in mind was per-user incremental restrictions, so that you wouldn't have to root-admin to further restrict processes you run as a regular user. This wouldn't have to be in kernel memory, maybe as a user-level daemon in a protected memory area or something.

Again, sorry if these are silly and/or useless suggestions. And good job on grsecurity, it's a great system, cheers

[andutt]

My tip and dreams of grsecurity, now i havent looked on the new patch to 2.4.20 kernel, maybe something are included there.

1: More logging, even if you have used gradm -a everything should be logged to kernellog for more easier tracing in case of changes of important system files.

2:Userroles that you can put on groups or on specifiec users, for example DBA:s can have access to the oracle directory and have the right to stop and start the database.

Keep up the good job!

[Murphy]

Not such an important thing but it would help if grsec logs were timestamped so you know exactly when a problem occurred.

- arnán

[goodbyte]

Not such an important thing but it would help if grsec logs were timestamped so you know exactly when a problem occurred.

Doesn't your syslog daemon do that for you?

[aldem]

wouldnt it make more sense to use SHA1 sums rather than md5's because of security (uniqueness)

No, it wouldn't. The complexity of breaking even MD5 sum is so high that it is easy to use conventional ways to break into the system (direct access, social engineering etc).

Regular hacker will refuse to try to break once he sees something non-trivial (and MD5 is not already), non-regular (or someone who really wants to get in) will get in anyway, one way or another.

Unless you are fighting with someone like NSA, you don't need "military grade" protection measures Hey, if it is NSA or like, you are in trouble anyway, and even SHA-512 won't help you

[gkweb]

Hi,

i don't use yet ACL system but i have few feature request :

1 - i saw that we can globally disable ACLs, but i really like the feature provided by LIDS which allow us to have a free shell, and only one, free of ACLs system, where we can do all that we want.
It could be usefull for instance when i am connected by SSH on my server to be able to disabled ACLs temporarly to install and build binaries without disable the global security.

2- documentation request : i perfectly understand that all your time is dedicated to work and improvement of grsecurity, but more documentation and howto would be greatly appreciated. For instance, it's hard to know what options we will have in the kernel until we are in, a global description would be nice (a summary).
I'm dedicated to my security, i use and configure in depth some advanced feature of my linux server, but the fact that i lack of documentation about grsecurity blocks me at some points, for instance about ACL, i'm unable to use them and try to use per application learning mode without blocking all my system. I know grsecurity is a best to have, a must, better by far than other security product that i saw, but i think that few users give up (that i was close to do!) because of not finding answers on official documentation (i don't know so good grsecurity to do them myself).
So i think that more documention will help to the spread of grsecurity, and to configure it!
(more doc about cvs would be great too, not toward cvs itself (man is good for) but to retrieve a ".patch" file for instance...)

3 - I think it could be good to choose password algorithm cipher, that we could configured regarding our state and local laws, i know that you can't force people to use some strong key like 2048 bits also, regardless of the cipher.

4 - for production use : a special option at building time of kernel allowing to secure it disabling the possibility for gradm to manage it, i mean ACLs are loaded at start and no program at all can disabled the protection
(had to reboot on normal grsecurity kernel to manage ACL).
Of course if the grsecurity password is totally unbreakable and 100% secure, this option is useless

5 - last : keep it the good work !! the most important request

regards,

gkweb.

[fd0]

1 - i saw that we can globally disable ACLs, but i really like the feature provided by LIDS which allow us to have a free shell, and only one, free of ACLs system, where we can do all that we want.
It could be usefull for instance when i am connected by SSH on my server to be able to disabled ACLs temporarly to install and build binaries without disable the global security.

grsec 1.9 has 'gradm -a', which gives you a 'free shell' and in grsec2 you are able to define an admin role, so this is already implemented (if i got you right...).


What I would really like to see is ipv6-support in acl (binding, connecting and from where you can connect for role assignment). Perhaps we can switch to ipv4-in-ipv6 notation in general (for example ::ffff:192:168:0:1), that shouldn't be hard to implement...

But thanks for the really great work you did, Brad.

- Alexander

[RaYmAn]

Hi
I would like to see local only roles, i.e. like IP based roles, just only allowing it when logged in locally on the machine.
Regards,
Jens Andersen

[msi]

i would like to be able to restrict a special group to a few programs. Together with the Trusted Path Execution this would be a really good technic to restrict the users permissions (keep in mind that chroots require enormous space and rbash is not a real solution too).