[Fedora-livecd-list] Preventing access to /mnt/live (inter alia)

Mads Kiilerich mads at kiilerich.com
Fri Mar 5 16:15:24 UTC 2010


On 03/05/2010 04:15 PM, James Heather wrote:
>>> (1) I want to stop non-root users from being able to mount other drives,
>>> e.g., other USB sticks. How do I do that? (It's not enough to kill off
>>> the auto-mounting if people will still be able to mount from the command
>>> line.)
>>
>> You probably want to configure polkit (PolicyKit in F11) to not allow
>> local users to do such administrative tasks.
>> I would start looking at
>> /etc/polkit-1/localauthority.conf.d/60-desktop-policy.conf (perhaps
>> /etc/PolicyKit in F11).
>> Or perhaps it could be solved at DeviceKit-disks level ...
>
> You da man. For the record, what I now have is
>
> %post
> #all non-root users need root password to mount anything
> if [[ -x /usr/bin/pklalockdown ]]
> then
> 	#this is for F12+
> 	pklalockdown --lockdown org.freedesktop.devicekit.disks.filesystem-mount
> else
> 	#this is F11-specific
> 	polkit-action --set-defaults-active org.freedesktop.devicekit.disks.filesystem-mount auth_admin
> fi
> %end
>
> which seems to work nicely.

Thanks - I will keep that on record ;-)

>> But how will you prevent the users from booting another USB stick where
>> they have full root access and from which they can open, run and hack
>> your usb stick?
>
> I can't. But then, I can't install software to stop them chatting to
> each other. Some of the security has to be down to careful invigilation.
>
> The only way to solve this by technical means would be to install the OS
> on the hard drive, or on a PXE server, or some such. But sadly I don't
> have the authority to do that.
>
> The alternative is to use the 'secure' environment that they have set up
> in Windows... where blocking network access means installing something
> in IE8 to stop them browsing forbidden web sites! But it doesn't block
> anything else, and we're giving them a compiler for goodness' sake.

You can't remove so much functionality from the system that you have a 
usable system with network connection where users can't easily "chat". 
But you can install a firewall which blocks all outgoing and/or incoming 
connections. That will be secure as long as the users don't get root access.

IMHO, if the users have physical access to the machines then the only 
way to prevent them from getting root access is surveilance.

I think that the right solution to your use-case is to use a managed 
switch and firewall. From your description it seems like management of 
its on/off button would be sufficient?

(That reminds me of the RHCE examn - fun stuff ...)

>>> (2) On a more relevant point for this list, I've noticed that all users
>>> have access to the base FAT32 filesystem of the bootable USB stick,
>>> on /mnt/live. How do I get this mounted so that only root can
>>> read /mnt/live? I don't want someone to be able to write code to unpick
>>> the squashfs image, etc. These are programming exams, so they have a
>>> compiler available, and a few of them can probably use it...
>>
>> I assume that everything in the squashfs already is mounted on / , so
>> what are you trying to avoid?
>
> They don't have unfettered access to /. They aren't root, so they can't
> (for instance) read or write /etc/shadow. But they can read and
> write /mnt/live/LiveOS/squashfs.img!

Are you sure?

In my experience /mnt/live is owned by root (modulo the confusion in 
https://bugzilla.redhat.com/show_bug.cgi?id=518702).

> Worse still, they can read/write the persistent overlay. That means it
> would be pretty easy to overwrite any file at all. They could install
> their own /etc/shadow with some judicious manipulation of the overlay.

Why are you using an overlay? Wouldn't if be sufficient to use a 
persistent home?

> I want to be sure that, provided they've booted from the stick I've
> given them, they can't break the security.

I think that the important and not-rethoric-at-all question is: How do 
you define security here? Exactly what are they not allow to - and why - 
and what must they be able to do?

IMHO
/Mads


More information about the livecd mailing list