grsecurity forums

Hey,
First i would like to thank your for your hard work and efforts in getting a Global security system like this working.. You have done a great job!

Now, ive noticed in some freebsd servers and some other linux distros that when u try delete your .bash_history file it spits out

rm: .bash_history: Operation not permitted

The file permissons are

-rw------- 1 steve steve 2894 Nov 25 01:27 .bash_history

As u can see its owned by me and my group... Even if i try and chmod it or anything else it just says Operation not permitted..

I would like add the same feature to my Linux Server(s), would also want to protect a few other files like .bash_history

Is this possible using Acl's? Since we cant use wildcards in Acl's i dont really think this would be possible?

Also would u happen to have an ETA on the new grsecurity with support for uid/gid permissions in ACL's?

Thanks
/Steve

you can't modify it most likely because it has the immutable flag set. You can set this using chattr +i and remove it using chattr -i. By default the ACL system remove CAP_LINUX_IMMUTABLE, so that not even root can remove the immutable flag from a file. Note that making the .bash_history immutable is pretty silly unless you have a specific reason to do it. That reason shouldn't be because you think it keeps someone from hiding what they're doing in the shell, as all the person has to do is modify the HISTFILE environment variable.

Roles will most likely be done over my christmas break. I'm going to attack roles and nested ACLs at the same time.

-Brad

If you want to log everything a user is doing you can give them the bash2 shell, patched with bofh patch (check Google for it) and leave them no opportunity to change their shell. GrSec also has exec logging (right?). Basically does the same, in another way. Btw HISTFILE vars can be setted 'read only'. Personally i don't do this stuff anymore since i trust my users and respect their privacy OR don't give them access.

Steve wrote:Hey,
First i would like to thank your for your hard work and efforts in getting a Global security system like this working.. You have done a great job!

Now, ive noticed in some freebsd servers and some other linux distros that when u try delete your .bash_history file it spits out

rm: .bash_history: Operation not permitted

The file permissons are

-rw------- 1 steve steve 2894 Nov 25 01:27 .bash_history

As u can see its owned by me and my group... Even if i try and chmod it or anything else it just says Operation not permitted..

I would like add the same feature to my Linux Server(s), would also want to protect a few other files like .bash_history

Is this possible using Acl's? Since we cant use wildcards in Acl's i dont really think this would be possible?

Also would u happen to have an ETA on the new grsecurity with support for uid/gid permissions in ACL's?

Thanks
/Steve

all you have to do is
chattr +i filename

now it is immutable
to remove the protection
as root type chattr -i filaname

Still nothin gto stop the user
from doing
export HISTFILE=/dev/null

Using .bash_history is a poor method to track what a user is doing. As stated above you can bypass it with HIST_FILE. You could force HIST_FILE but then the user could just kill -9 bash instead of logging out which will cause it not to log the session

I'm not sure if the kill -9 trick works with BOFH patch but the best way to log I'd think would be to set grsec to log all exec's, configure syslog-ng to match whatever ya wanted to do, then just grep/page through those logs.

Also about the +i immutatable flag you guys were talking about, chances are the ppl were using +a instead (append only).

It makes no sense to +i.

About chattr +i or +a flag. That only works for ext2 or ext3 fs, I'm using reiserfs, and I can't set those atribbutes so grsec is my only hope to prevent deleting of files. And +i is good method for script kiddies. Here's example in grsec
/ {
/ r
/opt rx
/home rwx
/home/*/.bash_history rax
/mnt rw
/dev
...
...
}

Like I said before, the best method is to enable logging of all exec's and chdirs in grsecurity and use the grsecurity logging to monitor which uid/ip does what. There are too many ways to get around .bash_history and it was never designed to monitor/spy on users.

Best way is to have as many proofs for nasty users as possible