New answer (2015-03-22)
(Note: This answer is simpler than previous, but not more secure. My first answer is stronger because you could keep files read-only by fs mount options before permission flags. So forcing to write a files without permission to write won't work at all.)
Yes, under Debian, there is a package: fsprotect (homepage).
It use aufs
(by default, but could use another unionfs
tool) to permit live session changes but in RAM by default, so everything is forgotten at reboot.
You could install them by running simply:
apt-get install fsprotect
Once done, from online doc:
After that:
- Edit
/boot/grub/menu.lst
or /etc/default/grub2
or /etc/lilo.conf
and add "fsprotect=1G
" to kernel parameters.
- Modify 1G as needed.
- Apply changes (i.e. run
update-grub
)
- Edit
/etc/default/fsprotect
if you want to protect filesystems other than /
.
- reboot
You may also want to password protect the grub bootloader or forbid any changes to it.
From there, if some file is protected against changes, for sample by
chmod ugo-w myfile
if you use for sample vi myfile
and try to write on it with command :w!
, this will work and your myfile
became changed. You may reboot in order to retrieve unmodified myfile
.
That's not even possible with my following first solution:
Old (first) answer:
Yes, it is a strong solution, but powerfull!
Making r/o useable
You have to mount some directories in rw, like /var
, /etc
and maybe /home
. This could by done using aufs or unionfs. I like this another way, using /dev/shm
and mount --bind
:
cp -a /var /dev/shm/
mount --bind /dev/shm/var /var
You could before, move all directories who have not to change in normal operation in a static-var
, than create symlinks in /var:
mkdir /static-var
mkdir /static-var/cache
mkdir /static-var/lib
mv /var/lib/dpkg /static-var/lib/dpkg
ln -s /static-var/lib/dpkg /var/lib/dpkg
mv /var/cache/apt /static-var/cache/apt
ln -s /static-var/cache/apt /var/cache/apt
... # an so on
So when remounting in ro, copying /var
in /dev/shm
won't take too much space as most files are moved to /static-var
and only symlinks are to be copied in ram.
The better way to do this finely is to make a full power-cycle, one day of full work and finely run a command like:
find / -type f -o -type f -mtime -1
So you will see which files needs to be located on read-write partition.
Logging
As in this host no writeable static memory exist, in order to store history and other logs, you have to config a remote syslog
server.
echo >/etc/syslog.conf '*.* @mySyslogServer.localdomain'
In this way, if your system break for any reason, everything before is logged.
Upgrading
When running whith some mount --bind
in use, for doing such an upgrade while system is in use (whithout the need of running init 1
, for reducing down-time), the simplier way is to re-build a clean root, able to do the upgrade:
After remounting '/' in read-write mode:
mount -o remount,rw /
for mpnt in /{,proc,sys,dev{,/pts}};do
mount --bind $mnpt /$mnt$mpnt;
done
chroot /mnt
apt-get update && apt-get dist-upgrade
exit
umount /mnt/{dev{/pts,},proc,sys,}
sync
mount -o remount,ro /
And now:
shutdown -r now
Best Answer
A read-only
/etc
is increasingly common on embedded devices. A rarely-changing/etc
is also increasingly common on desktop and server installations, with files like/etc/mtab
and/etc/resolv.conf
located on another filesystem and symbolically linked in/etc
(so that files in/etc
need to be modified when installing software or when the computer's configuration changes, but not when mounting a USB drive or connecting in a laptop to a different network).The emerging standard is to have a tmpfs filesystem mounted on
/run
and symbolic links in/etc
likeExisting or embedded systems may have the tmpfs mounted on a different location such as
/dev/shm
or/lib/init/rw
or/var/run
.The problem with making
/etc
read-only is that this locks the set of files that you'll ever be able to modify.A different approach that avoids this problem is to make the root filesystem an initramfs. This is an archive that's stored next to the kernel image and loaded by the bootloader. It is unpacked into RAM and becomes the root of the root of the filesystem. If you're going to let the initramfs stick around, it shouldn't be too big (because it's using up precious RAM), but a BusyBox binary plus some configuration files may be an acceptable use of RAM.
Another approach is to have a read-only root filesystem plus a union mount of a read-write filesystem.