|
From: Tim T. <t....@co...> - 2004-04-27 04:14:59
|
I came across what I think is a small security hole. At least it happens on my system, I think it is not unique. When the save-config script makes the etc.tar.bz2 file, it leaves it world-readable (0644). Any unpriveleged user who can mount the storage device can then copy the file to their own directory or machine, and access the files that are root-read-only, for example "shadow" and crack passwords etc at their leisure. This patch chmods the etc.tar.bz2 file after successful creation to 0600. Also, I moved the "post-save-config" script check and call to before the umount of the etc.tar.bz2 location, in the belief that the work of "post-save-config" script would be alot easier if it didn't have to go and rediscover (possibly in error) where the file save-config just wrote is stored... also, it shouldn't be run if the save failed I think. While I'm on the topic, I think another pontential hole is the linuxrc script that discovers the etc.tar.bz2 file on boot... since multiple locations are checked, if an unpriveleged user can introduce an etc.tar.bz2 file onto a drive that is checked before the real one, then they can control the machine on the next reboot. We should check the file for "root" ownership and that it is not writeable by anyone else before loading it. Of course not being a bash master I'm not sure how to write that... Tim |