taking feature requests

[Technion]

MD5 sums are expensive to calculate. A full tripwire run along my computer takes over a minute. You don't want that sort of delay with every execution.
If you want this feature, install tripwire.
If you want it working on the fly, have a small policy that just checks /bin, /sbin and /usr/bin and run it hourly from cron.

[spender]

The ACL system is the perfect answer to that...we ensure that all binary paths specified in PATH are protected against writing. The only kind of trojan that the ACL system won't immediately prevent for you would be ones that you download and run without checking the signatures on the website (like what happened recently with monkey.org). Of course this is no different than intentionally running a malicious binary, which you can always restrict with the ACL system prior to running.

-Brad

[flamingice]

Can you have some way of disabling module loading/unloading while the kernel running? This would be good for systems that need modules but don't want rootkits running and don't need to unload/load modules after the system is booted. (Like mine, of course)

Maybe it could also be a sort of ACL thing where only certain modules specified can be loaded/unloaded..

[blueberry]

A sysctl to control kernel module loading could be a good idea.

And to rehash my idea of MD5, i'm not looking for the thing to run
on a fileserver or compileserver, but on my firewall box.

On that box, having MD5's calculated wouldn't hurt me at all.
Yes, it'd probably take 2 more minutes to boot, but then again i'm not
rebooting it 6 times a day anyway...

-blue

[Cyt0plas]

And to rehash my idea of MD5, i'm not looking for the thing to run
on a fileserver or compileserver, but on my firewall box.

On that box, having MD5's calculated wouldn't hurt me at all.
Yes, it'd probably take 2 more minutes to boot, but then again i'm not
rebooting it 6 times a day anyway...

Ok, there will be two conditions when your computer is running.
1) Kernel security is off. Without MD5, your binaries can be replaced. With MD5, they could just change the stored hashes. Either way, you're screwed. But if its _your_ firewall, why would it be off anyway, unless you turned it off?
2) Kernel security is on. Why check the signatures when you just make them read only in the first place? Don't let them get modified. Heck, on a firewall box, you could easily get away with making almost the whole thing read only.

Sample (incomplete) ACL:
/ rx
/var rwx
/var/log ar
/firewall/logs ar

Every binary in the system would be protected against overwriting or trojaning, as long as security is on. When security is off, MD5 won't help anyway.

[Himika]

I suggest you giving more flexibility to gradm. Imagine my system is loaded with lots of runining tasks. Each of them requires specific rights, so I simply want to create an ACL such as:

/ {
/ rwxa
/etc/tripwire h
/usr/sbin/tripwire h
}

/usr/sbin/tripwire h {
/ rxo
/etc/tripwire rwxa
}

/usr/sbin/crond {
/usr/sbin/tripwire rxo
}


And gradm won't accept it.... I think it's up to the admin and the system requirements what to deny/allow. This strictly behaviour of gradm doesn't appeal to me. Imagine I wanna run slightly secured Linux box, not a scaring jail which throws away the users:)

[spender]

gradm only enforces enough things so that the security of the system can't be bypassed. If you want a false sense of security, then you should probably be using another system.

-Brad

[Himika]

I don't think so:) Paranoia sometimes isn't the only way of implementing security... never mind, I just played a bit with your source in order to satisfy my requirements. IMHO, nobody can say or define what "false security" is or what fine security means. That's where the options and the flexibility come to help sysadmins develop their favourite solutions.

[spender]

Let me know when someone modifies your kernel via /dev/mem, disabling the ACL system, and then replaces your tripwire app with a shell script that mails you every day telling you there's no changed files on the system. I don't see any purpose whatsoever for tripwire unless it's being used in a honeypot. If you don't want files to be modified, don't allow them to be modified. Don't have some program spit out a log when it happens while you're sleeping or on vacation.

-Brad

[Va|eK]

even tho it can be done with other programs things id liek to see is liek say liek in lids a port scan detection system.
a way to make sure that the file limit exploit cannot be exacuted

generally stuff liek that.

[OwNeR]

Hello

Maybe a Feature to limit background processes?
Something like grsec check a file count the
running processes and kill all processes over the
limit number after starting automaticly?

Thanks for the very nice work !!!

[Va|eK]

Another thing id like to see in future releases is something to do with pax that does not break xfreee86 w/o having to use chpax and baybe a builtin portscanner even tho you can do this with external programs. and maybe a better default acl sys.

[Va|eK]

Another thing id like to see in future releases is something to do with pax that does not break xfreee86 w/o having to use chpax and baybe a builtin portscanner even tho you can do this with external programs. and maybe a better default acl sys.

but its a very good imporov emnt so far to the kernel keep up the good work and than you for addressing my concern about the open file limit in the kernel.


-- Va|eK

[PaX Team]

Another thing id like to see in future releases is something to do with pax that does not break xfreee86 w/o having to use chpax

unfortunately this is not something one could fix in the kernel, it is an XFree86 problem: they invented their own executable module loading system (instead of using dlopen() or its logic at least) which allocates memory for the code via calloc() and such memory happens to be not executable which PaX enforces (there might be other issues as well, but this is the first point where PaX intervenes).

[goodbyte]

Couldn't pax be included as a capablilty? so if I like to grant pax to XFree86 I would do:

/usr/X11R6/bin/XFree86 {
+CAP_PAX

...
}

I also would like better inherit configuration. like:

/etc/rc.d/rc.S {
+CAP_...

/etc/rc.d/rc.inet2 {
+CAP...
}
}

so the capability fo /etc/rc.d/rc.inet2 would only be used if started from /etc/rc.d/rc.S

Keep up the good work!