No, my / is not mounted read-only by accident, it’s on purpose. However, it still can be (re)mounted in write mode.
I’m trying to setup a read-only configuration in a way that not even root can (re)mount is in write mode. So in GRUB I added the RO parameter to boot read-only. Opensuse 11 and 12 differ a bit. OS11 indeed has / read-only after boot, OS12 only has / read-only if it is specified RO in the /etc/fstab. But in both cases root can remount / in write mode.
Any idea how I can get the / to be truly read-only?
No sure what you mean: Do you want to protect your root filesystem from accidents or from malicious software running as root?
In the former case, mounting with ro in fstab should be enough, it’s unlikely you or some program remounts it rw by accident.
In the latter case, this can only accomplished with hardware support (e.g. a disk with a read-only switch or maybe a special BIOS setting). The root user can do anything and everything by design. If a malicious program runs with super-user powers it can load its own kernel module, issue commands directly to the hardware and write anything to the disk as long as the hardware permits. This cannot be changed by the kernel or grub. This is also true for every other operating system.
Both cases apply. And even more. It should also prevent any authorized user through sudo to change the base server machine. The changes they could make are not necessarily malicious but also not by accident. They can change the software base without formal testing and/or approval. (for instance replace a certain binary just because they like that one better.) We would like to have a default base system to be enrolled to every system and make sure no one can change that software base.
In our virtual machine on s390 we can set a disk to read-only outside the guest machine, indeed basically the same as a read-only switch. That way we can prevent writing to the disk. I was hoping to be able to do the same, or similar, in a PC. If a BIOS setting could do that that would be nice, but I guess that would apply to the entire disk, not limited to the / partition.
I would prefer to have a way to have it in GRUB so that only the / partition could be set read-only. That way I could set the default boot to a read-only configuration. In the boot menu I could have an option to boot in a writable configuration only when needed. That would limit the number of people with write access to only the ones with access to the physical machine. Ah, well, we have to find another way then.
On 2012-05-04 11:06, berryvansleeuwen wrote:
>
> Hi All,
>
> No, my / is not mounted read-only by accident, it’s on purpose.
> However, it still can be (re)mounted in write mode.
>
> I’m trying to setup a read-only configuration in a way that not even
> root can (re)mount is in write mode. So in GRUB I added the RO parameter
> to boot read-only. Opensuse 11 and 12 differ a bit. OS11 indeed has /
> read-only after boot, OS12 only has / read-only if it is specified RO in
> the /etc/fstab. But in both cases root can remount / in write mode.
IMO, root will always be able to try (re)mount R/W. This will fail if the
device itself is read only, like a cdrom.
On 2012-05-04 12:06, berryvansleeuwen wrote:
> In our virtual machine on s390 we can set a disk to read-only outside
> the guest machine, indeed basically the same as a read-only switch. That
> way we can prevent writing to the disk. I was hoping to be able to do
> the same, or similar, in a PC. If a BIOS setting could do that that
> would be nice, but I guess that would apply to the entire disk, not
> limited to the / partition.
Loop mount it as a r/o file and do it as in the link I gave.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)
IMHO there is nothing you can do against the user root writing to a disk (partition) from within the OS. Even when a partition is mounted* ro*, root can still write to the device special file. Even one character suffices to destroy the file system or the partition table.
As said above, only write protection from outside the OS works. And you suggest GRUB somewhere, but GRUB is not realy outside the OS. Many people seem to think that all that is* inside menu.ls*t are GRUB parameters. But many of the things there are Kernel parameters. As soon as during boot GRUB finds the Kernel to boot, it passes those parameters on to the Kernel (GRUB does not even understand what that text string means).
On 2012-05-04 12:36, berryvansleeuwen wrote:
>
> Hi Carlos,
>
> In general I like links rather than copying content but I’m not able to
> enter bugzilla. So i’m not able to look at the link you provided.
I tried clicking on it and it works here :-?
But I thought of another idea: create the filesystem as an ISO image, which
can not be written to.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)
On 2012-05-04 13:06, hcvv wrote:
>
> IMHO there is nothing you can do against the user -root- writing to a
> disk (partition) from within the OS. Even when a partition is mounted-
> ro-, root can still write to the device special file. Even one character
> suffices to destroy the file system or the partition table.
True.
However, if the root filesystem is one that by design is read only, like
the ISO image of a dvd, you can not write to it. And you can not umount it
to change something, because then you don’t have a system running.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)
Yes, the link works fine, but in bugzilla it asks for a registration code.
Creating an ISO image sounds interesting, maybe I can try that.
I would expect the kernel to respect the RO parameter, as passed by GRUB, in a way that a remount would fail. The kernel has been instructed to use a read-only root disk so it should know it is (or should be) read-only. Granted, it might still be possible to write to a device but at least this would take more effort than remount the / filesystem.
Thus it is only on boot. Nowhere any mentioning of blocking later mounting in another way. Would be rather strange in any case because depending on what is in the root partition, every system configuration change and even a security update would be made impossible.
I do not completely understand what you try to achieve and why. But to me it seems that you have “authorised users” (authorised to do what?) that shouldn’t be. The Unix/Linux principle is clear: a user can/may not change the system, only root can/may. This is independent of the fact if you like that principle. Thus either you trust somebody to be root (and preferable implement some checking of accountability) or you don’t.
Using sudo for some exceptions is possible, but they must be exceptions and well thought over and implemented. And not to much of them because they then become unmanagable.
hcvv wrote:
> I do not completely understand what you try to achieve and why. But to
> me it seems that you have “authorised users” (authorised to do what?)
> that shouldn’t be. The Unix/Linux principle is clear: a user can/may not
> change the system, only -root- can/may. This is independent of the fact
> if you like that principle. Thus either you trust somebody to be -root-
> (and preferable implement some checking of accountability) or you don’t.
Exactly. You either must impose technical security (prevent spys etc),
which means the users can’t be root, or else you impose human security
(have the organization work efficiently), which means codes of conduct
and firing people who don’t follow the rules.
> Using -sudo- for some exceptions is possible, but they must be
> exceptions and well thought over and implemented. And not to much of
> them because they then become unmanagable.
OK, look at it the other way, why would the / disk be mounted read-only at boot, only to remount it writable later on? If the boot parameter is set to RO shouldn’t there be a reason for that? Because it is a read-only disk (such as an ISO) or because we want to prevent write access other than after a reboot and selecting the writable menu option?
Indeed, an update for whatever reason is impossible. That’s the goal. Whenever an update is required it is changed once in the baseline and then distributed in a controlled way. Changes are only allowed after testing and approval. This way we can ensure only a tested configuration will be enrolled and we can provide proof to auditors for that. As a bonus, migrations are so much easier this way.
In a way this is technical security. On the one hand prevent someone to gain (root)access to the machine. But if someone does, either by accident or on purpose, make sure he can’t do any harm anyway.
Indeed, the best way would be to have as few root users in the system as possible. But some groups do not agree, even some software vendors do not agree.
Why would it be hard to mount /var? The /var is a seperate partition, just as /tmp and /srv. So we can just mount that on the var directory in the read-only /.
On 05/04/2012 10:36 AM, berryvansleeuwen wrote:
>
> OK, look at it the other way, why would the / disk be mounted read-only
> at boot, only to remount it writable later on? If the boot parameter is
> set to RO shouldn’t there be a reason for that? Because it is a
> read-only disk (such as an ISO) or because we want to prevent write
> access other than after a reboot and selecting the writable menu option?
You may just have pointed to the Achilles heel of your argument. Is not the /
partition initially mounted read-only so that it can be fscked? If that is true,
then at least that utility can write to a RO disk. I think you need the external
write-lock switch.
Why would that be the Achilles heel? If it’s a read-only disk, there are never changes to the disk. So no open files or orphan inodes. Therefore a fsck is not needed for the disk and is disabled. Indeed, that utility could decide to write to the disk, so it is even not allowed for that disk. IIRC the boot.rootfsck and boot.localfs in OpenSuse 12 even skip the fsck if the root disk is (to be) mounted read-only.
fsck is working reading/writing on the partition, not on the file system. You should in principle run fsck on the unmounted file system to be sure there are no changes to the file system during checking. Of course there are also no changes when mounted ro. But the important thing here is that fsck does basicaly not care about it being mounted ro or not, it has nothing to do with that.
If fsck is working on the partition then why are there extentions on fsck, such as fsck.ext2, fsck.ext3 etc. I’d think that would mean it’s working on the filesystem (too).
Well, anyway, one can turn off the fsck so that’s what I have done. No need for an fsck on read-only disks.