Menu
▾
▴
devil-linux-develop
|
From: Tim T. <t....@co...> - 2004-04-27 04:14:59
Attachments:
save-config.diff
|
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 |
|
From: Bruce S. <bw...@ar...> - 2004-04-27 13:00:56
|
> 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. The chmod is a good idea. Can't be too safe! :-) > 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... That won't work because a regular user could run "chmod 600 etc.tar.bz2" and then a "chown root etc.tar.bz2" once they are done creating it. (unless we restrict execution of chown/chmod only to root) You'll have to make sure a normal user doesn't have write access to the root directory of any partition checked by linuxrc. Unless you have another idea .... ? - BS |
|
From: Heiko Z. <he...@zu...> - 2004-04-27 13:31:17
|
> > 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... The only real secure way to prevent this is by using the gpg signing of the configuration. Currently only root is allowed to mount, but I found another hole in /etc/fstab, where a user is allowed to mount the floppy. I will turn this off imediately. -- Regards Heiko Zuerker http://www.devil-linux.org |
|
From: Tim <t....@co...> - 2004-04-27 17:16:34
|
Heiko Zuerker wrote: >>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... >> >> > >The only real secure way to prevent this is by using the gpg signing of >the configuration. > >Currently only root is allowed to mount, but I found another hole in >/etc/fstab, where a user is allowed to mount the floppy. I will turn this >off imediately. > > I agree crypto gives the best security, but it is going to be complex, a management headache, and maybe more than most small installations need. The root only mount helps, but in some cases where the server has a hard drive used for stuff, it may already have a partion be mounted - say for tmp space. Now the user only needs to put the file there. I can look into how to check for root ownership and make a patch... Tim |
|
From: Heiko Z. <he...@zu...> - 2004-04-27 13:41:16
|
> > 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... I added the patch to 1.1.x and also updated 1.0.7. -- Regards Heiko Zuerker http://www.devil-linux.org |
|
From: Tim <t....@co...> - 2004-04-27 16:52:35
|
Bruce Smith wrote: >>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... >> >> > >That won't work because a regular user could run "chmod 600 etc.tar.bz2" >and then a "chown root etc.tar.bz2" once they are done creating it. >(unless we restrict execution of chown/chmod only to root) > >You'll have to make sure a normal user doesn't have write access to the >root directory of any partition checked by linuxrc. Unless you have >another idea .... ? > > - BS > Not true, a non-priveleged user can't reassign ownership to another user... I ran a quick test and confirmed it on my box. Tim |
|
From: Bruce S. <bw...@ar...> - 2004-04-27 17:21:58
|
> > > 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... > > > > > That won't work because a regular user could run "chmod 600 etc.tar.bz2" > > and then a "chown root etc.tar.bz2" once they are done creating it. > > (unless we restrict execution of chown/chmod only to root) > > > > You'll have to make sure a normal user doesn't have write access to the > > root directory of any partition checked by linuxrc. Unless you have > > another idea .... ? > > Not true, a non-priveleged user can't reassign ownership to another > user... I ran a quick test and confirmed it on my box. OK, that appears to be the case now. I haven't tried that for a long time on Linux. BTW, I can still do it on HP-UX 11.0, just tried it. That being the case, I'm still not sure it's worth checking in linuxrc. Mainly because not all filesystems support the concept of "owner". Especially floppies & USB memory sticks which are formatted as FAT. If you use LVM for your disk partitions (as specified in the DL docs), then you won't have the problem because linuxrc doesn't check LVM volumes. If you use normal partitions, make sure that their root directory is only root writable. That with the fact that normal users can't mount partitions should keep you safe. - BS |
|
From: Roland P. <pa...@ta...> - 2004-04-27 19:28:00
|
On Tuesday 27 April 2004 06:14, Tim Tait wrote: [...] > > 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... if you have several users on a system, the most dangerous part is rebooting. it's the only time a false config could be injected, but even worse: just pass init=/bin/bash and you have a root shell. So either: don't reboot, or: always attend your reboots and make sure the right config is loaded. If you want to disable command line passing, you have to change isolinux.cfg. When doing that, you can also add a "config=/dev/whatever" and if you protect that device properly, everything should be fine. of course, make sure no one swaps CD's and boots a rescue system... so, IMHO, root ownership may be an additional security check, but it's inferior to gpg signing (but maybe we should make that part easier...) Roland -- ICQ UIN 49339118 Linux Counter #88774 GPG-Key 1024D/59C6AFA6 2003-02-07 Roland Pabel <ro...@pa...> |
|
From: Heiko Z. <he...@zu...> - 2004-04-27 19:41:42
|
> On Tuesday 27 April 2004 06:14, Tim Tait wrote: > [...] >> >> 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... > if you have several users on a system, the most dangerous part is > rebooting. > it's the only time a false config could be injected, but even worse: just > pass init=/bin/bash and you have a root shell. So either: don't reboot, > or: > always attend your reboots and make sure the right config is loaded. > If you want to disable command line passing, you have to change > isolinux.cfg. > When doing that, you can also add a "config=/dev/whatever" and if you > protect > that device properly, everything should be fine. You can NEVER protect a system when somebody has access to the hardware. There are endless possibilities on how to gain access.... > of course, make sure no one swaps CD's and boots a rescue system... > so, IMHO, root ownership may be an additional security check, but it's > inferior to gpg signing (but maybe we should make that part easier...) Suggestions on how we can make it easier? At the moment you only put the public key on the CD and it's working. I think the signing of the config is the most complicated part, since you have to get the etc.tar.bz2, sign it and copy the signature to the config media. -- Regards Heiko Zuerker http://www.devil-linux.org |
|
From: Roland P. <pa...@ta...> - 2004-04-27 20:19:54
|
On Tuesday 27 April 2004 21:39, Heiko Zuerker wrote: > > On Tuesday 27 April 2004 06:14, Tim Tait wrote: > > [...] > > [...] > > > > if you have several users on a system, the most dangerous part is > > rebooting. > > it's the only time a false config could be injected, but even worse: just > > pass init=/bin/bash and you have a root shell. So either: don't reboot, > > or: > > always attend your reboots and make sure the right config is loaded. > > If you want to disable command line passing, you have to change > > isolinux.cfg. > > When doing that, you can also add a "config=/dev/whatever" and if you > > protect > > that device properly, everything should be fine. > > You can NEVER protect a system when somebody has access to the hardware. > There are endless possibilities on how to gain access.... That's true, that "everything" was an overstatement... > > of course, make sure no one swaps CD's and boots a rescue system... > > so, IMHO, root ownership may be an additional security check, but it's > > inferior to gpg signing (but maybe we should make that part easier...) > > Suggestions on how we can make it easier? > At the moment you only put the public key on the CD and it's working. That's nothing we can change, unless you bring the public to the system every time you boot. Improvement's could be: - automatic key pair generation on custom build - use keys the user supplies (both via menuconfig) > I think the signing of the config is the most complicated part, since you > have to get the etc.tar.bz2, sign it and copy the signature to the config > media. the private key must be supplied by root somehow. If he (the admin) is personally present at the system, we could search for the gpg key on another medium (for example usb-stick...) If not, that's difficult...copying the archive around and signing without knowing how the admin wants to access it, no way... Roland -- ICQ UIN 49339118 Linux Counter #88774 GPG-Key 1024D/59C6AFA6 2003-02-07 Roland Pabel <ro...@pa...> |
|
From: Tim <t....@co...> - 2004-04-27 20:01:36
|
Roland Pabel wrote: >On Tuesday 27 April 2004 06:14, Tim Tait wrote: >[...] > > >>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... >> >> >if you have several users on a system, the most dangerous part is rebooting. >it's the only time a false config could be injected, but even worse: just >pass init=/bin/bash and you have a root shell. So either: don't reboot, or: >always attend your reboots and make sure the right config is loaded. >If you want to disable command line passing, you have to change isolinux.cfg. >When doing that, you can also add a "config=/dev/whatever" and if you protect >that device properly, everything should be fine. >of course, make sure no one swaps CD's and boots a rescue system... >so, IMHO, root ownership may be an additional security check, but it's >inferior to gpg signing (but maybe we should make that part easier...) >Roland > DL supports passing the etc.tar.bz2 file location from boot program? Cool! And is it just isolinux or does Grub and Lilo work too parameter passing from hard disk boots? This would solve a major headache for me - I don't want DL scanning all 7 or 8 disk partitions and floppies, usb etc. I just want to tell it load the one on hda1, or the floppy. I can make grub menu picks for those. Can/does this parameter also get read by save-config? My 2nd big concern is a config be written back to somewhere other than it came from. As Bruce pointed out, the floppy FAT doesn't support ownership attributes, so that may not help. But if I can force the etc.tar.bz2 location from the boot string, which already has a config file that is root only access, then a non priveleged user can not overwrite it so thats even better. Tim |
|
From: Roland P. <pa...@ta...> - 2004-04-27 20:29:34
|
On Tuesday 27 April 2004 22:01, Tim wrote: > Roland Pabel wrote: > >On Tuesday 27 April 2004 06:14, Tim Tait wrote: > >[...] > > [...] > > DL supports passing the etc.tar.bz2 file location from boot program? yes, I added that a few weeks ago., See the mailing list archive or press F3 at the boot screen The essentials: - config=/dev/hda1:backup.tar.bz2 will search for that file on that device first - config=/dev/hda1 will scan that device first - config=backup.tar.bz2 will scan all devices for that archvie first > Cool! And is it just isolinux or does Grub and Lilo work too parameter > passing from hard disk boots? This would solve a major headache for me - I guess, would surprise me otherwise...but haven't ever booted DL from a harddrive...isolinux,grub and lilo can also protect the boot options, making them un-editable... > I don't want DL scanning all 7 or 8 disk partitions and floppies, usb > etc. I just want to tell it load the one on hda1, or the floppy. I can > make grub menu picks for those. Can/does this parameter also get read by > save-config? My 2nd big concern is a config be written back to somewhere > other than it came from. We could add more features like: - exclusive: scan only one device - lists: config=/dev/hda1,/dev/hda2 ... > As Bruce pointed out, the floppy FAT doesn't support ownership > attributes, so that may not help. But if I can force the etc.tar.bz2 > location from the boot string, which already has a config file that is > root only access, then a non priveleged user can not overwrite it so > thats even better. that shouldn't be a problem... Roland -- ICQ UIN 49339118 Linux Counter #88774 GPG-Key 1024D/59C6AFA6 2003-02-07 Roland Pabel <ro...@pa...> |
