On Saturday 24 May 2008 12:05:30 Fred Noz wrote:
Responding to a question posted earlier this month, Centos 5.1 includes configuration files for enabling the read-only root filesystem. Actually, all filesystems can be mounted read-only with particular files and directories mounted on a read-write tmpfs (in RAM). This capability comes directly from the upstream provider.
When your computer comes back up, the root and any other system partitions will be mounted read-only. All the files and directories listed in /etc/rwtab will be mounted read-write on a tmpfs filesystem. You can add additional files and directories to rwtab to make them writable after reboot.
Note that this system is stateless. When you reboot again, everything written to the tmpfs filesystem vanishes and the system will be exactly as it was the last time it was booted. You could add a writable filesystem on disk or NFS for writing files you want to retain after rebooting.
This is very interesting. Thanks for the sharing Fred. So, it's somekind of Live CD on a disk? I can't think of a practical benefit of using such system, is it to protect it from unwanted modification?
Fajar Priyanto | Reg'd Linux User #327841 | Linux tutorial -----
Fajar, There are many practical reasons why one would want to run a Linux system, whether it be desktop or server, with a read-only root.
One reason is for ease of maintenance, especially when there are many systems to maintain. You might be administering computers in a classroom, internet access point, or library and you want to be certain that after reboot, the system is exactly as it was the last time it was rebooted, even if the users mess with the system accidentally or on purpose.
For example, if a user fills up the /tmp filesystem and causes the system to crash, after booting, the system will have an empty /tmp filesystem. It will not require that fsck to be run because the other filesystems were mounted read-only. This implies no risk of filesystem corruption (except due to physical failures on the disk). Not needing fsck saves time on boot.
You could use read-only root on embedded systems where there is no way an administrator could get to the system to fix it.
Read-only root is beneficial on a system running on flash media because this avoids having recurring writes wear out some sectors on the media.
This is a practical way to run a large group of diskless systems. A single read-only root filesystem can be made available on a network from an NFS server. Many diskless clients can use this readonly-root simultaneously.
Of course, this is a way to implement a live CD.
In addition to easy maintenance, readonly-root adds a layer of security. The security is broken if someone gains access to the root user, but then many security protections are lost if someone gains root.
Even a Database server can benefit from being run on read-only root. The data disk would certainly be mounted read-write, but there is no reason why the operating system and database application software need to be on disks mounted read-write.
When an administrator wants to perform an update, upgrade, software, installation. or other system change, the administrator sets the readonly filesystems to read-write using a simple mount command. After the administrator finishes making the changes, a simple mount command (or reboot) sets the readonly filesystems back to read-only.
Of course, on systems where the root and system filesystems have no physical write capability, such as on a live CD, they cannot be set to read-write.
- Fred --------- Fred Noz Fred@Noz.net
A very big thanks
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100 - - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, purge the message from your system and notify the sender immediately. Any other use of the email by you is prohibited.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Fred Noz Sent: Saturday, May 24, 2008 1:30 PM To: centos@centos.org Subject: [CentOS] read only root file system
On Saturday 24 May 2008 12:05:30 Fred Noz wrote:
Responding to a question posted earlier this month, Centos 5.1 includes configuration files for enabling the read-only root filesystem. Actually, all filesystems can be mounted read-only with particular files and directories mounted on a read-write tmpfs (in RAM). This capability comes directly from the upstream provider.
When your computer comes back up, the root and any other system partitions will be mounted read-only. All the files and directories listed in /etc/rwtab will be mounted read-write on a tmpfs filesystem. You can add additional files and directories to rwtab to make them writable after reboot.
Note that this system is stateless. When you reboot again, everything written to the tmpfs filesystem vanishes and the system will be exactly as it was the last time it was booted. You could add a writable filesystem on disk or NFS for writing files you want to retain after rebooting.
This is very interesting. Thanks for the sharing Fred. So, it's somekind of Live CD on a disk? I can't think of a practical benefit of using such system, is it to protect it from unwanted modification?
Fajar Priyanto | Reg'd Linux User #327841 | Linux tutorial
Fajar, There are many practical reasons why one would want to run a Linux system, whether it be desktop or server, with a read-only root.
One reason is for ease of maintenance, especially when there are many systems to maintain. You might be administering computers in a classroom, internet access point, or library and you want to be certain that after reboot, the system is exactly as it was the last time it was rebooted, even if the users mess with the system accidentally or on purpose.
For example, if a user fills up the /tmp filesystem and causes the system to crash, after booting, the system will have an empty /tmp filesystem. It will not require that fsck to be run because the other filesystems were mounted read-only. This implies no risk of filesystem corruption (except due to physical failures on the disk). Not needing fsck saves time on boot.
You could use read-only root on embedded systems where there is no way an administrator could get to the system to fix it.
Read-only root is beneficial on a system running on flash media because this avoids having recurring writes wear out some sectors on the media.
This is a practical way to run a large group of diskless systems. A single read-only root filesystem can be made available on a network from an NFS server. Many diskless clients can use this readonly-root simultaneously.
Of course, this is a way to implement a live CD.
In addition to easy maintenance, readonly-root adds a layer of security. The security is broken if someone gains access to the root user, but then many security protections are lost if someone gains root.
Even a Database server can benefit from being run on read-only root. The data disk would certainly be mounted read-write, but there is no reason why the operating system and database application software need to be on disks mounted read-write.
When an administrator wants to perform an update, upgrade, software, installation. or other system change, the administrator sets the readonly filesystems to read-write using a simple mount command. After the administrator finishes making the changes, a simple mount command (or reboot) sets the readonly filesystems back to read-only.
Of course, on systems where the root and system filesystems have no physical write capability, such as on a live CD, they cannot be set to read-write.
- Fred
Fred Noz Fred@Noz.net
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Sat, May 24, 2008 at 8:29 PM, Fred Noz Fred@noz.net wrote:
In addition to easy maintenance, readonly-root adds a layer of security. The security is broken if someone gains access to the root user, but then many security protections are lost if someone gains root.
However, this should *never* be used alone for security concerns. A compromiser can easily run that simple mount command to remount read-write after root access. But sometimes before gaining root access, some system spesific files are over-written to gain root access with the help of exploits.. This helps keeping from them.
Linux wrote:
However, this should *never* be used alone for security concerns. A compromiser can easily run that simple mount command to remount read-write after root access.
I've been reading some of your recent comments, Anonymous looser, and I've really got to say this - you seem to make some authoritative style comments on things you really dont know much about. eg. in this case - the filesystem could be mounted readonly since its only exposed readonly from the underlying i/o or block subsystem.
- KB
On Mon, May 26, 2008 at 2:15 AM, Karanbir Singh mail-lists@karan.org wrote:
I've been reading some of your recent comments, Anonymous looser, and I've really got to say this - you seem to make some authoritative style comments on things you really dont know much about. eg. in this case - the filesystem could be mounted readonly since its only exposed readonly from the underlying i/o or block subsystem.
Thank you for your comments. Next time I'll try to stop my ego... I guess you are right. An authorative style would mean nothing without an identity.
A cd-rom can provide security as a readonly mount, but readonly mounted ordinary filesystem/disk means almost nothing. Dont you read comments like "administrator remounts read-write"? Why?
I dont know, I like to be an a**hole looser I think.
Linux wrote:
A cd-rom can provide security as a readonly mount, but readonly mounted ordinary filesystem/disk means almost nothing. Dont you read comments like "administrator remounts read-write"? Why?
If your blockdev is exposed to the OS as 'ro', your administator can go jump off a cliff if he wants, he's not geting +w on there.
On Sun, May 25, 2008 at 7:47 PM, Karanbir Singh mail-lists@karan.org wrote:
Linux wrote:
A cd-rom can provide security as a readonly mount, but readonly mounted ordinary filesystem/disk means almost nothing. Dont you read comments like "administrator remounts read-write"? Why?
If your blockdev is exposed to the OS as 'ro', your administator can go jump off a cliff if he wants, he's not geting +w on there.
Hmmm... interesting.
Is there a way to force the OS to see a SCSI disk or partition as a "ro" blockdev like this? Nobody who doesn't have physical access cannot write to the root filesystem. And yet you might be able to reboot the machine (in "rw" mode, maybe another entry in grub menu?), do your updates, and reboot the machine again turning it read-only. It would be very useful indeed from the security point of view.
Thanks, Filipe
Filipe Brandenburger wrote:
Is there a way to force the OS to see a SCSI disk or partition as a "ro" blockdev like this? Nobody who doesn't have physical access cannot write to the root filesystem. And yet you might be able to reboot the machine (in "rw" mode, maybe another entry in grub menu?), do your updates, and reboot the machine again turning it read-only. It would be very useful indeed from the security point of view.
Quite a few HBA's which have out-of-band management interfaces will let you do something like this, even let you take a single disk collection, carve it up into volumes, and set read/write acl's per volume.
-
Filipe Brandenburger -
Fred Noz -
Jason Pyeron -
Karanbir Singh -
Linux