Prevent delete of ~/.bash_history

Submit your RBAC policies or suggest policy improvements

Prevent delete of ~/.bash_history

Postby Steve » Mon Nov 25, 2002 9:38 am

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
Steve
 
Posts: 5
Joined: Mon Nov 25, 2002 9:30 am

Postby spender » Mon Nov 25, 2002 12:53 pm

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
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm

Postby dystopia » Mon Dec 02, 2002 7:32 pm

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.
dystopia
 
Posts: 14
Joined: Sun Jun 30, 2002 5:05 pm

Re: Prevent delete of ~/.bash_history

Postby ameen » Thu Feb 06, 2003 9:08 pm

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
ameen
 
Posts: 10
Joined: Sat Oct 12, 2002 9:22 pm

Postby TGKx » Wed Feb 19, 2003 10:32 am

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.
TGKx
 
Posts: 50
Joined: Wed Feb 19, 2003 4:39 am

Postby szpak » Wed Mar 26, 2003 7:13 am

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
...
...
}
szpak
 
Posts: 10
Joined: Wed Mar 26, 2003 7:08 am

Postby TGKx » Thu Mar 27, 2003 1:53 am

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.
TGKx
 
Posts: 50
Joined: Wed Feb 19, 2003 4:39 am

Postby szpak » Thu Mar 27, 2003 6:40 am

Best way is to have as many proofs for nasty users as possible ;)
szpak
 
Posts: 10
Joined: Wed Mar 26, 2003 7:08 am


Return to RBAC policy development

cron