LinuxQuestions.org - vi changing owner and group on a force write

- Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)

- - vi changing owner and group on a force write (https://www.linuxquestions.org/questions/linux-security-4/vi-changing-owner-and-group-on-a-force-write-490674/)

vi changing owner and group on a force write

Hi all,

Noticed a problem in one of my backup scripts this morning on our file server to fix it. SSH direct and login as my own username (phillips), change to the script dir and list. Note that the script backup-email.sh is owned by root and root:

Quote:

login as: phillips
phillips@x.weatherbeeta.com.au's password:
[phillips@kiama ~]$ cd /admin/scripts/
[phillips@kiama scripts]$ ll
total 40K
-rwxr-xr-x 1 root root 453 Sep 20 09:16 backup-email.sh*
-rwxr-xr-x 1 root it 706 Aug 15 17:05 backup.PDF-Reporting*
-rwxr-xr-x 1 root it 284 Jul 31 12:54 ftp.nz*
-rwxr-xr-x 1 root it 280 Jul 28 13:02 ftp.uk*
-rwxr-xr-x 1 root it 250 Aug 2 10:02 ftp.usa*
[phillips@kiama scripts]$

Edit this script and force write because I'm still user phillips and file permissions are 755 so in theory I can't write to the file. And now the file is owned by 'phillips' and group 'it', file permissions are the same:

Quote:

[phillips@kiama scripts]$ vi backup-email.sh
[phillips@kiama scripts]$ ll
total 40K
-rwxr-xr-x 1 phillips it 407 Oct 9 09:02 backup-email.sh*
-rwxr-xr-x 1 root it 706 Aug 15 17:05 backup.PDF-Reporting*
-rwxr-xr-x 1 root it 284 Jul 31 12:54 ftp.nz*
-rwxr-xr-x 1 root it 280 Jul 28 13:02 ftp.uk*
-rwxr-xr-x 1 root it 250 Aug 2 10:02 ftp.usa*
[phillips@kiama scripts]$

Double check that I am still phillips:

Quote:

[phillips@kiama scripts]$ id
uid=1157(phillips) gid=1009(it) groups=0(root),101(ssh),512(Domain Admins),513(Domain Users),544(Administrators),551(Backup Operators),1008(ssh),1009(it),1010(root),1015(system) context=user_u:system_r:unconfined_t

Yep! Now given that I didn't have write permissions in the first place (group = r-x yes I'm in the root group, naughty me), why:
a) was I allowed to write the file in the first place?
b) change the permissions to be owned by me?

Is it because I'm in the root group, or something to do with the 'unconfined' errors when I id my user? Would this allow 'any' user to modify my scripts for their own purposes?! :eek:

This box is a RedHat ES4 running Samba and LDAP as our network's PDC.

Any input would be great :)

That is odd, but check your umask in your bash profile. Maybe there's something funky in your sshd config

I haven't touched umask settings in bashrc - they are the same as my other RHES4 boxes:

From /etc/bashrc :

Quote:

if [ "`id -gn`" = "`id -un`" -a `id -u` -gt 99 ]; then
umask 002
else
umask 022
fi

The only mods I've made to SSHd config is:
1) Only accept Protocol 2
2) Disallow root Login
3) Only accept members of the ssh group
4) Display /etc/issue.net after username entry

I also checked vim's permissions and it doesn't have SUID set or anything:

Quote:

[phillips@kiama ~]$ ll /usr/bin/vim
-rwxr-xr-x 1 root root 2.0M Aug 11 2005 /usr/bin/vim*

I might try replicating this at the console and see if it will happen there. I'll also try it on my development RHES4 box. Will post again when I've done that.

Cheeers,
-p

Just tried this at the console and on my development box and they both do the same thing :(

I also tried it from a "normal" user who's not in the root group and it also works...

A write does not only modify the file but also the directory the file is in. Octal DAC mode of /admin/scripts (stat -c %a /admin/scripts) should show world-write or sticky bit. BTW, having human users ($UID >= $UID_MIN, /etc/login.defs) in the root group is a bad thing. What reasons do you have for weakening your systems security posture?

[phillips@kiama /]$ stat -c %a /admin/scripts
775

We have our admin staff (2 users) in the root group to allow modifications to config files etc, without the need for file operations while as root (rm -Rf /data = even worse than users in root group!) - we have a bad bad bad habit of logging in and going straight to 'su -' to do anything we need. This is my first step is trying to eliminate that :D

A write does not only modify the file but also the directory the file is in. Octal DAC mode of /admin/scripts (stat -c %a /admin/scripts) should show world-write or sticky bit.
[phillips@kiama /]$ stat -c %a /admin/scripts
775
Yeah, or group mode ;-p

we have a bad bad bad habit of logging in and going straight to 'su -' to do anything we need.
Well, I sudo over to root to do stuff too, but I log into an unprivved account and from there use Rootsh as shell wrapper. This doesn't guard against human error but does leave a nice logging trail.

We have our admin staff (2 users) in the root group to allow modifications to config files etc, without the need for file operations while as root
If it's manual changes in config files (not using std RH tools) then you could build a wrapper for that: the idea is to have all changes in versioning repo (I still use RCS for that), check out a copy of the config and on change diff and store and then replace the config. This way you have root access but not to the working config, always have central backup to fall back on and a changelog. The "challenge" would be to build in some form of logic checking between diff and replace to warn against fatal errors...

[phillips@kiama /]$ stat -c %a /admin/scripts
775
Yeah, or group mode ;-p
So because one of the groups on my login has group rwx permissions to the folder, I can force writes to the file, even though the permissions on the specific file don't allow me to?

I sudo over to root to do stuff too, but I log into an unprivved account and from there use Rootsh as shell wrapper
That's where I'm trying to move to - I haven't heard of Rootsh though, I'll look in to it. `history` is a very mediocre audit trail of commands :S

the idea is to have all changes in versioning repo
We do a basic way of this. We comment any and all changes to config files at the start and end of our modification with our initials, a description of the change if appropriate and the date, and comment the old setting, then add our own. For a basic example, in smb.conf:

Code:

[global]

  netbios name = Kiama

  # BEG MOD PHS 13.10.06

  # We're not in the dodgy M$ default workgroup anymore!

  #workgroup = WORKGROUP

  workgroup = WBAUS

  # END MOD PHS 13.10.06

  server string = File Server

If we're going to make major changes to a file then we take a copy to somewhere else first (eg, our home directory), and we have a daily script that does a tar.gz backup to our File Server, which then goes to tape which includes /etc and so forth

"sudo chmod +t /admin/scripts/" will prevent this..

Yes, vi does this.
The logic is like, even though phillips doesn't have write permissions on the file backup-email.sh, he does have write permissions to the directory scripts.
So phillips is well within his permissions to delete the already existing file backup-email.sh and write a new one in the same name.

This can be overcome by adding sticky bit to the directory permissions (sudo chmod +t /admin/scripts/).
Sticky bit means that, even though everyone has write permissions to the directory, one can delete a file only if he is owner/root.