Hi, I'm setting up a firewall with 6.4. At the moment, I'm trying to secure the machine. I wanted to set the /-FS to readonly, only /home,/var,/tmp are writable. All works fine, but after closing a tty, mingetty is respawning too fast and I'm unable to use this tty any more. I tracked the problem down to an write-attempt to the cua-device, but the system reports that / is mounted readonly. Is there a possibility to supress this write-access in the respawning-process? -- Stefan Bauer
Hi,
I'm setting up a firewall with 6.4. At the moment, I'm trying to secure the machine.
I wanted to set the /-FS to readonly, only /home,/var,/tmp are writable. All works fine, but after closing a tty, mingetty is respawning too fast and I'm unable to use this tty any more.
I tracked the problem down to an write-attempt to the cua-device, but the system reports that / is mounted readonly.
Is there a possibility to supress this write-access in the respawning-process?
Hi Stefan, A write attempt to some device file on a read-only mounted filesystem is legitimate and should be successful as long as no filesystem changes are involved. If you consider a device file a "hole" in the filesystem, this behaviour might be more transparent to you. The problem is that mingetty tries to chown(2) and chmod(2) the device file. You'd have to ensure that these non-ro operations are successful. This can be done by mounting a ramdisk over /dev soon after the kernel boot, and before /dev/pts is mounted. The next step would be to unpack a tarfile into that new ramdisk so that the device files are fully available when other processes open them later. It is imperative that this happens while no other process is running that could feel like opening a device file which isn't there yet. With some tweaking it is very well possible to have a read-only root-fs. But if you use this feature for security reasons, you also have to make sure that write access to the raw device is not possible either - a disk seems useless under these circumstances. Once it's finished, burn the ext2 filesystem on a CD and boot from it. Roman. -- _ _ | Roman Drahtmüller "The best way to pay for a | CC University of Freiburg lovely moment is to enjoy it." | email: draht@uni-freiburg.de - Richard Bach | - -
Roman Drahtmueller schrieb:
Hi Roman,
Hi Stefan,
A write attempt to some device file on a read-only mounted filesystem is legitimate and should be successful as long as no filesystem changes are involved. If you consider a device file a "hole" in the filesystem, this behaviour might be more transparent to you.
That is, what I thought that would happen, but I got the log-messages ...
The problem is that mingetty tries to chown(2) and chmod(2) the device
Ah, I didn't know of that. Now it's clear to me, what happens.
file. You'd have to ensure that these non-ro operations are successful. This can be done by mounting a ramdisk over /dev soon after the kernel boot, and before /dev/pts is mounted. The next step would be to unpack a tarfile into that new ramdisk so that the device files are fully available when other processes open them later. It is imperative that this happens while no other process is running that could feel like opening a device file which isn't there yet.
Good advice. I'll give it a try.
With some tweaking it is very well possible to have a read-only root-fs. But if you use this feature for security reasons, you also have to make sure that write access to the raw device is not possible either - a disk
Oh thanks, I haven't thougt about raw devices in this context.
seems useless under these circumstances. Once it's finished, burn the ext2 filesystem on a CD and boot from it.
Hmmm, sounds good. Thanks, Roman, now I think I can get running in the way I want it. Bye -- Stefan Bauer
Hi,
I'm setting up a firewall with 6.4. At the moment, I'm trying to secure the machine.
I wanted to set the /-FS to readonly, only /home,/var,/tmp are writable. All works fine, but after closing a tty, mingetty is respawning too fast and I'm unable to use this tty any more.
I tracked the problem down to an write-attempt to the cua-device, but the system reports that / is mounted readonly.
Is there a possibility to supress this write-access in the respawning-process?
Also try LIDS, you can be much more selective and set things that need to be writeable writeable. www.lids.org Kurt Seifried SecurityPortal, your focal point for security on the net http://www.securityportal.com/
Kurt Seifried wrote: Hi Kurt :-)
I wanted to set the /-FS to readonly, only /home,/var,/tmp are writable. All works fine, but after closing a tty, mingetty is respawning too fast and I'm unable to use this tty any more. I tracked the problem down to an write-attempt to the cua-device, but the system reports that / is mounted readonly. Is there a possibility to supress this write-access in the respawning-process? [cut] Also try LIDS, you can be much more selective and set things that need to be writeable writeable.
www.lids.org
Well, this requires some changes in the boot script of SuSE Linux, too. I wrote a small How-To including patches for SuSE 6.0-6.4 - but it's a bit outdated (in LIDS 0.9.x the concept was changed, i.e. stuff which could only be configured via the kernel configuration can now be done via the new lidsadm tool). But I hope it's still usefull - comments are of course welcome. :-) I'm currently busy with hacking on AMaViS and my new Linux/Unix Anti Virus Project, so I'll have no time to update it soon. You can get it at: http://www.cn.is.fh-furtwangen.de/~link/security/LIDS-SuSE.php3 Btw, the german mirror can be reached at www.de.lids.org. HTH best regards, Rainer Link -- Rainer Link | Member of Virus Help Munich (www.vhm.haitec.de) rainer@w3.to | Member of AMaViS Development Team (dev.amavis.org) rainer.w3.to | Maintainer FAQ "antivirus for Linux" (av-linux.w3.to)
participants (4)
-
Kurt Seifried -
Rainer Link -
Roman Drahtmueller -
Stefan Bauer