On 07/01/2012 10:23 AM, John Wendel wrote:

Extra security is certainly a plus. My main reason for wanting to run a
read-only root it to avoid wearing out the consumer grade compact flash
card that I'm using as my root device (yes, I'm cheap).


I'd suggest, then, using a distro that doesn't update as frequently as
Fedora. /sbin is on the root device and you'd need to set it to rw
every time one of its programs gets updated. Also, if you're using
Fedora, have a separate /boot that's not on that card to make kernel
updates easier.

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Am 01.07.2012 19:32, schrieb Joe Zeff:
> On 07/01/2012 10:23 AM, John Wendel wrote:
>> Extra security is certainly a plus. My main reason for wanting to run a
>> read-only root it to avoid wearing out the consumer grade compact flash
>> card that I'm using as my root device (yes, I'm cheap).
>
> I'd suggest, then, using a distro that doesn't update as frequently as Fedora. /sbin is on the root device and
> you'd need to set it to rw every time one of its programs gets updated. Also, if you're using Fedora, have a
> separate /boot that's not on that card to make kernel updates easier.

i do it the other direction

/var/cache, /var/lib, /boot, /var/tmp, /var/log and /tmp on own partitions
or in case of virtual machines even on drives because i can have rootfs as
small as possible without fearing it gets full

this would have the same effect without the problem of have to
remeber remount rw before updates

with "yum-plugin-security" and "yum update --security" you can
even on Fedora minimize updates most of the time if you really
want while you can update packages selective from the normal
repos if a update fixes a bug which affects you

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

John Wendel wrote:
> Is it possible to setup Fedora, using Fedora provided
> tools/software, with a read-only root partition?

As I understand it, /etc does have to be on /. So you will need to
either set up network user authentication, or live with any local users
not being able to change their passwords (or possibly symlink
/etc/shadow off /, but I’d expect trouble with that idea…)

There used to be problems with /etc/mtab, but now that’s just a symlink
to /proc/mounts, that isn’t a problem any more.

Hope this helps,

James.

--
E-mail: james@ | The opinions expressed herein are not necessarily those
aprilcottage.co.uk | of my employer, are not necessarily mine, and in fact are
| probably not necessary at all...
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

On 2012/07/01 10:25, Reindl Harald wrote:



Am 01.07.2012 19:23, schrieb John Wendel:

On 07/01/2012 10:11 AM, Reindl Harald wrote:


Am 01.07.2012 19:08, schrieb Joe Zeff:

On 07/01/2012 10:01 AM, John Wendel wrote:

Is it possible to setup Fedora, using Fedora provided tools/software,
with a read-only root partition?

There's an ancient wiki entry from the FC6 days that indicates that some
work was done, but I would assume that this depended on the SysV init
system. I've haven't seen any mention of read-only root setup with systemd.

Any clues would be greatly appreciated.


If I'm not mistaken, /var needs to be on that partition and needs to be writable.

it is not uncommon to have /var on a own partition


If so, then you can't have a
read-only root partition.

it works, but be really carefull


And, just so we all know where we're going here, why would you want to?

in theory more security

imagine a root-exploit changing a system binary
much more difficult if the rootfs is readonly


Extra security is certainly a plus. My main reason for wanting to run a read-only root it to avoid wearing out the
consumer grade compact flash card that I'm using as my root device (yes, I'm cheap)


even if it works - you have ALWAYS to remember remount it rw
on any yum-update - i personally would not do it because
of some hardware


The equivalent is done with live CDs you know.

{^_^}
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

On 07/01/2012 12:17 PM, jdow wrote:

[SNIP]



The equivalent is done with live CDs you know.

{^_^}


I think you just supplied the answer! I didn't think of it, but the
equivalent of a live CD is exactly what I need. Now I just need to
figure out how to build a live CD like system, minus the compressed
filesystem stuff and I should be there.


I should have mentioned earlier that this box is going to be a dedicated
media player, with the compact flash drive as it's only disc. I know I
should probably just use openelec or geexbox, but that would take all
the fun out of it. I will try to steal the init system from one of these
dedicated distributions, but I really want to build the system with
Fedora packages as much as possible.


Thanks everyone for sharing your knowledge.

John


--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

John Wendel <jwendel10 <at> comcast.net> writes:

>
> On 07/01/2012 12:17 PM, jdow wrote:
> > [SNIP]
>
> > The equivalent is done with live CDs you know.
> >
> > {^_^}
>
> I think you just supplied the answer! I didn't think of it, but the
> equivalent of a live CD is exactly what I need. Now I just need to
> figure out how to build a live CD like system, minus the compressed
> filesystem stuff and I should be there.
>
> I should have mentioned earlier that this box is going to be a dedicated
> media player, with the compact flash drive as it's only disc. I know I
> should probably just use openelec or geexbox, but that would take all
> the fun out of it. I will try to steal the init system from one of these
> dedicated distributions, but I really want to build the system with
> Fedora packages as much as possible.
>
> Thanks everyone for sharing your knowledge.
>
> John
>

The live CD systems that I've dealt with have all created a minimal, in-RAM /
(or root) using ramfs. Just boot with your favorite live CD distro, open a
terminal and run mount. It does mean that the image of / can be read-only and
it takes surprisingly little RAM to have the bits of Linux in RAM that are
actually volatile.

Cheers,
Dave


--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Reindl Harald wrote:



Am 01.07.2012 19:08, schrieb Joe Zeff:

On 07/01/2012 10:01 AM, John Wendel wrote:

Is it possible to setup Fedora, using Fedora provided tools/software,
with a read-only root partition?

There's an ancient wiki entry from the FC6 days that indicates that some
work was done, but I would assume that this depended on the SysV init
system. I've haven't seen any mention of read-only root setup with systemd.

Any clues would be greatly appreciated.



If I'm not mistaken, /var needs to be on that partition and needs to be writable.


it is not uncommon to have /var on a own partition


If so, then you can't have a
read-only root partition.


it works, but be really carefull


And, just so we all know where we're going here, why would you want to?


in theory more security

imagine a root-exploit changing a system binary
much more difficult if the rootfs is readonly

Not clear if that really would help or not, setting attribute immutable on
selected things makes them pretty bulletproof, although for the projected use I
doubt it would be an issue.


The problem is that Linux doesn't support a overlay filesystem, sort of like
copy on write, but at the inode level. That will allow you to "change" files all
you want, but the working copy goes elsewhere.


I run tests using COW copies of disk images, so the original can be shared and
will remain unchanged. I bet a system using a cheap flashcard for root doesn't
have a VM capable CPU, or the root could be tiny and the app could run in a
throwaway VM, recreated at boot time.


See: qemu-img create -b real.img -f qcow2 single-use.img

Booting off the copy will put changes in an image which can be discarded, or you
can run multiple VMs off a single image.



--
Bill Davidsen <davidsen@tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot


--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Reindl Harald wrote:



Am 01.07.2012 19:32, schrieb Joe Zeff:

On 07/01/2012 10:23 AM, John Wendel wrote:

Extra security is certainly a plus. My main reason for wanting to run a
read-only root it to avoid wearing out the consumer grade compact flash
card that I'm using as my root device (yes, I'm cheap).


I'd suggest, then, using a distro that doesn't update as frequently as Fedora. /sbin is on the root device and
you'd need to set it to rw every time one of its programs gets updated. Also, if you're using Fedora, have a
separate /boot that's not on that card to make kernel updates easier.


i do it the other direction

/var/cache, /var/lib, /boot, /var/tmp, /var/log and /tmp on own partitions
or in case of virtual machines even on drives because i can have rootfs as
small as possible without fearing it gets full

What does that buy? If /tmp fills many things stop working even if it is on a
non-root filesystem. And to the extent that applications and services depend on
the other trees you mention breakage will occur, although far fewer things will
be broken filling anythig other than /tmp.



this would have the same effect without the problem of have to
remeber remount rw before updates

with "yum-plugin-security" and "yum update --security" you can
even on Fedora minimize updates most of the time if you really
want while you can update packages selective from the normal
repos if a update fixes a bug which affects you






--
Bill Davidsen <davidsen@tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot


--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Am 02.07.2012 19:35, schrieb Bill Davidsen:
> Reindl Harald wrote:
>>
>>
>> Am 01.07.2012 19:32, schrieb Joe Zeff:
>>> On 07/01/2012 10:23 AM, John Wendel wrote:
>>>> Extra security is certainly a plus. My main reason for wanting to run a
>>>> read-only root it to avoid wearing out the consumer grade compact flash
>>>> card that I'm using as my root device (yes, I'm cheap).
>>>
>>> I'd suggest, then, using a distro that doesn't update as frequently as Fedora. /sbin is on the root device and
>>> you'd need to set it to rw every time one of its programs gets updated. Also, if you're using Fedora, have a
>>> separate /boot that's not on that card to make kernel updates easier.
>>
>> i do it the other direction
>>
>> /var/cache, /var/lib, /boot, /var/tmp, /var/log and /tmp on own partitions
>> or in case of virtual machines even on drives because i can have rootfs as
>> small as possible without fearing it gets full
>>
> What does that buy? If /tmp fills many things stop working even if it is on a non-root filesystem. And to the
> extent that applications and services depend on the other trees you mention breakage will occur, although far fewer
> things will be broken filling anythig other than /tmp

what this does buy?
if a disk gets too small it is much easier stp the vm
and make the /tmp-drive larger than resize rootfs

and if /var/log fills the rootfs nor /tmp are filled
if /tmp fills you have a change to see it in any log

i am not speaking about workstations here
these are server-configurations working fine since many years

on some of them there is a larger extra virtual-disk and the
list above is BIND-mounted there which has the same effect:
less writes to rootfs and a much smaller rootfs

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org