Read Only Root disk

On 2012-05-04 18:56, berryvansleeuwen wrote:
> IRC the boot.rootfsck and boot.localfs in OpenSuse 12 even skip
> the fsck if the root disk is (to be) mounted read-only.

No, it doesn’t.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

On 2012-05-04 17:36, berryvansleeuwen wrote:
>
> 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 /.

Because something is written to the system to register the mount.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

On 2012-05-04 17:36, 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?

That is the normal process of things. First R/O. then R/W.

> 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.

The live CD is such a R/O system, but modifications are done to it so that
the system doesn’t need to write to it, or writes are done in memory. You
can not directly use a R/O image, AFAIK.

> 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.

It is the first time I hear of such a procedure.

> 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.

There is only one root user.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

Yes, indeed, a change then requires a reboot in such a setup. Or rather, when enrolling a new release, with multiple fixes or even a new version, the old root disk will be replaced by a new one. So shutdown with the old disk, boot with the new disk. Downtime only seconds. A fallback in case if a failed migration, once again only seconds since the old disk is still available.

Regards, Berry.

I still don’t see the point. Any of the measures taken are against things that require root access anyway, and like Henk already said, “touching” the disk as root is easily done. Maybe you should search in the virtualization areas. That way you could maintain images, leave the host as default as possible, the VM for the user.

Indeed, a mount would write in /etc/mtab, it links to /proc/self/mounts. The /proc is a virtual filesystem and therefore not read-only.

Regards, Berry.

We are running the concept in virtual systems. So we do know that it works in virtual systems. Indeed, in virtual systems the disk is actually linked read-only. Now we’d like to see if we can do it in host systems too, or in any case something similar to it.

Regards, Berry.

Please also take a look at Welcome – SUSE Studio It’s one of the things that makes openSUSE/SUSE more than just a linux distro. You can create and maintain your own appliances, add files, Testdrive, even alter things through ssh when in testdrive. Not completely off topic, but could open new options for you

On 2012-05-04 23:06, berryvansleeuwen wrote:
>
> 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).

It works on two levels. The filesystem is mounted read only, so that no
files are altered, nothing can get altered. This is done so that fsck can
write to the filesystem, in the knowledge that nothing else writes to it.

It is mounted R/O, yes, but writes are not forbidden to the kernel. Only to
the filesystem.

And if fsck reports that it changed something, it has to reboot, can not
continue.

Had you read the bugzilla comment, you would have read that even when
mounting R/O a filesystem the kernel can write the journal to the disk. It
is not R/O strictly. This is a problem for forensics, for example.

> Well, anyway, one can turn off the fsck so that’s what I have done. No
> need for an fsck on read-only disks.

As I said, you have to do some serious modifications to the system - did
you think of auditing your own modifications? Because you are altering the
system :slight_smile:


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

> That is the normal process of things. First R/O. then R/W.

True, when running the default system. Then it mounts ro to do the fsck and then mounts rw. But why is there a kernel parameter ro? I would think that instructs the kernel to not mount rw during boot. And it has been for several SLES versions. Only now I’m trying to do the same with OpenSuse and it fails.

> The live CD is such a R/O system, but modifications are done to it so that
> the system doesn’t need to write to it, or writes are done in memory. You
> can not directly use a R/O image, AFAIK.

Too bad, but that was what I wanted to find out. So we can conclude that there is no way to have a truly read-only root disk.

> It is the first time I hear of such a procedure.

It’s standard operating procedure in the systems I work with. It has been so for years. Basically: secure your system to prevent harm, expect that doesn’t help and configure accordingly.

> There is only one root user.

Quite right, unfortunately. And to be able to do something other than ‘normal’ user behavior, most demand access to root. Usually just because root can do anything.

Regards, Berry.

On 2012-05-04 23:36, berryvansleeuwen wrote:
>
> Indeed, a mount would write in /etc/mtab, it links to /proc/self/mounts.
> The /proc is a virtual filesystem and therefore not read-only.

And /etc can not be a separate partition from /, but here it must.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

>> IRC the boot.rootfsck and boot.localfs in OpenSuse 12 even skip
>> the fsck if the root disk is (to be) mounted read-only.

> No, it doesn’t.

Oops, you are right. It would skip the remount in write mode but it doesn’t skip the fsck, at least not because of a ro parameter. But when looking at the code I noticed the parameter should be readonlyroot instead of ro. However, the grub manual mentions ro. And zipl (the s390 bootloader) also does need ro. So another thing to test.

Regards, Berry.

Right, /etc is a separate partition that gets mounted before init is started. Instead of directly running init from the cmdline, a script is executed that mounts /etc and then starts init.

Regards, Berry.

Puzzled. Parameter readonlyroot doesn’t mount / readonly in 11.4 but ro does.

boot.rootfsck:
if rc_cmdline readonlyroot ; then
echo “Skipping rw-remount of / since boot commandline specified “readonlyroot””

So:
bvs:~ # . /etc/rc.status
bvs:~ # rc_cmdline ro
bvs:~ # rc_cmdline readonlyroot
readonlyroot=yes

I’d think this would have mounted / in read-only but it only does that with parameter ro.

On 2012-05-04 23:56, berryvansleeuwen wrote:

>> the system doesn’t need to write to it, or writes are done in memory. You
>> can not directly use a R/O image, AFAIK.
>
> Too bad, but that was what I wanted to find out. So we can conclude
> that there is no way to have a truly read-only root disk.

Maybe it is, but not that easily. A live CD is done that way - but often
they allow writing to space on the hard disk.

>> There is only one root user.
>
> Quite right, unfortunately. And to be able to do something other than
> ‘normal’ user behavior, most demand access to root. Usually just because
> root can do anything.

There is no need to be root to work with a system, only the system
maintainer needs to be root. And even then, not all the the time.

If you need to work as root, your system is not designed properly.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

We’d like to keep the system as default as possible. A live-CD setup would probably just a bit too much to handle for some. But it would be an idea.

Indeed, root shouldn’t be needed. But as mentioned, some do not agree. Try installing Oracle or DB2. Or rather, others want to install it and complain we do not open up our system. In the end the manager forces us to assign full access. And later on complain to us when the system has been messed up by the root user. Even Yast usually requires root. Not a problem when I should do something but it is a problem when a DBA or network guru has the ability to switch to root and go outside his responsibilities. Anyway, that discussion is somewhat off-topic. It’s not so much preventing root access as it is preventing anyone, root included, to change the base coding at will.

Regards, Berry.

On 2012-05-05 01:16, berryvansleeuwen wrote:
>
> We’d like to keep the system as default as possible. A live-CD setup
> would probably just a bit too much to handle for some. But it would be
> an idea.
>
> Indeed, root shouldn’t be needed. But as mentioned, some do not agree.
> Try installing Oracle or DB2. Or rather, others want to install it and
> complain we do not open up our system. In the end the manager forces us
> to assign full access.

I don’t understand. It is your job to install Oracle, not theirs. If they
are root, they are responsible and it is their systems, not yours anymore.

What are you doing?


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

If I have root I can umount a ro partition and remount rw so I don’t understand the problem. Seems to me to be a organization problem not asystem problem. In any case making the / or portions ro really does not help since your problem users still won’t be able to install arbitrary programs. and now you have to totally build a new image every time. I simply can’t imagine the problems that will occur. Seems to me that it much simpler to simply not give users root and install additional stuff on request by a trusted tech.

Another thing is the OpenSUSE by the fact a new version is released about every 6 months and support stops in about 18 months is not normally suitable for a Enterprise environment.

I came until here in reading the new posts in this thread after a night of fine sleep (thank you).
You do not seem to understand much about this subject. There are no “extentions” of* fsck*. fsck is the general program. It is called with a partition (not a file system!) as parameter. It will try to find out what type of file system is on that partition. When it succeeds, it will then call the fsck program dedicated to that file system type. One can also do this call of e.g.* fsck.ext4* directly, saves a few milisecs of processing. This fsck.<name-of-file-system-type> is just a convention. The word “extention” (IIRC deriving from MS-DOS file systems which have such a thing as a seperate field in the metadata of a file) has no meaning here.

Of course there is an fsck dedicated to every type of file system. Every file system type has it’s own inernal structure and fsck has the task to check that structure and eventaly repair it. Thus every file system type comes with it’s own fsck version (made by the designers of that type of file system).

The (dedicated to a file system type) fsck program still gets a device file as parameter. It checks the file system on that device file and when needed repairs it (and thus writes to it). Remember that “it” is still the device file. Thus as long as the process running that fsck version has write access to the device file it can do repairs. Normaly the device file is owned by root and has write access for the owner. E.g. here is that situation for the partition that has my root file system:


boven:~ # mount | grep ' / '
/dev/sda2 on / type ext4 (rw,relatime,user_xattr,acl,barrier=1,data=ordered)
boven:~ # ls -l /dev/sda2
brw-rw---- 1 root disk 8, 2 May  5 09:21 /dev/sda2
boven:~ #

As you can see root is the owner of* /dev/sda2* and has write access. Thus any process (e.g. an fsck.ext4) can write to /dev/sda2. Regardless of the fact if it is mounted at all, or mounted ro or mounted with whatever parameters.
And, as explained many timees, preferably the file system should not be mounted when running fsck because else the structure to be checked/repaired may change during that checking/repairing by normal usage.

HTH

And in the end it is of course “only” an organisational problem.

There is only one person/department responsible for system management. And it is only that person/department that has root access. When your management does not accept that, you better look for another job.

I know it is a hard battle. but you are the system manager, you are the expert. You should of course also try to provide as good a service as possible to Database Adminisrators, etc. But you have your resposabilities and they have theirs. When your management does not accept this, they will fail any security assesment from outside.