Hi all,
What I'm trying to do is to create a bunch of Fedora USB sticks for use in practical examinations at uni. The existing Windows setup in the labs is pretty woeful, and the only way I can be in control of the environment is to boot up off something else.
I have it working pretty nicely, but I have a few issues I'm not sure how to resolve.
(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.)
(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...
(3) The write cache is good, and makes the whole system feel very responsive, but if a machine crashes or there's a power cut, I'm in danger of them losing lots of work. Is there a way of decreasing the maximum "dirty" time for writes to the USB stick? I have found lots of info on doing this for vm paging, but not for the filesystem itself. All I've found is how to turn off the cache altogether (mount with 'sync'), but that's not an option because everything will run much too slowly. I'd far rather set an option to ensure that everything gets written at most a minute after entering the cache.
It would be really handy to solve these without resorting to selinux. I have had some trouble with selinux and the USB sticks, and I would prefer to leave it disabled. But if selinux is by far the easiest solution, I can probably work with it.
(I don't know if it's relevant, but currently I have to build this as Fedora 11, because my first go is a 3D graphics exam, and they need the proprietary ATI driver.)
Thanks for the help!
James
On 03/05/2010 11:11 AM, James Heather wrote:
Hi all,
What I'm trying to do is to create a bunch of Fedora USB sticks for use in practical examinations at uni. The existing Windows setup in the labs is pretty woeful, and the only way I can be in control of the environment is to boot up off something else.
I have it working pretty nicely, but I have a few issues I'm not sure how to resolve.
(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 ...
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 think you should focus on creating an USB stick where you can guarantee that it works unless they shoot them self in their foot.
(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?
(I don't know if it's relevant, but currently I have to build this as Fedora 11, because my first go is a 3D graphics exam, and they need the proprietary ATI driver.)
That is almost the same as giving them root access.
(Just kidding. I really don't know. But neither do you. ;-) )
/Mads
(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.
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.
(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!
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.
I want to be sure that, provided they've booted from the stick I've given them, they can't break the security.
(I don't know if it's relevant, but currently I have to build this as Fedora 11, because my first go is a 3D graphics exam, and they need the proprietary ATI driver.)
That is almost the same as giving them root access.
(Just kidding. I really don't know. But neither do you. ;-) )
Fortunately, nor do they!
James
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
fre 2010-03-05 klockan 10:11 +0000 skrev James Heather:
(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...
Maybe you should just install Fedora to the USB stick instead of using the Live tools. (Oups, sorry list. :) )
I'd suggest manually partitioning the stick using parted to make sure partitions are properly aligned (by even 128KiB is probably best), before booting into Anaconda. Also parted needs "units B" to make it actually follow what the user enters. (Anaconda is supposed to align partitions according to hints from the drive, but if the drive doesn't hint, you're on your own, it seems.)
(I don't know if it's relevant, but currently I have to build this as Fedora 11, because my first go is a 3D graphics exam, and they need the proprietary ATI driver.)
The experimental MESA driver (r600_dri) works very well for me, at least for driving Compiz. (I switched back to composited Metacity though.)
Maybe you should just install Fedora to the USB stick instead of using the Live tools. (Oups, sorry list. :) )
I did look at this. The main trouble is that I don't have room! I'm installing 5GB+ of stuff, and they're 4GB sticks. I could probably trim it down, but the point is to install everything that might be used for other exams in the foreseeable future.
The compression does a brilliant job--it takes it down to under 2GB, leaving me plenty for overlay and persistent home.
(One of the few things I miss from my Windows days is the per-file compression in NTFS. It would be really great to see that in ext2.)
I got them all to do their lab session using the sticks last week, and it worked perfectly--in fact, it was noticeably snappier than booting into Windows from the hard drive!
The one thing left to sort is the write cache. One of the machines crashed, and one of them lost quite a lot of her work because it hadn't hit the usb stick by then.
(I don't know if it's relevant, but currently I have to build this as Fedora 11, because my first go is a 3D graphics exam, and they need the proprietary ATI driver.)
The experimental MESA driver (r600_dri) works very well for me, at least for driving Compiz. (I switched back to composited Metacity though.)
Yes, it works fine for Compiz. It just won't cut it for OpenGL stuff, though. When I run the exam using the mesa driver, I get about 3fps.
James
J.Heather@surrey.ac.uk wrote, On 03/06/2010 10:42 AM:
The one thing left to sort is the write cache. One of the machines crashed, and one of them lost quite a lot of her work because it hadn't hit the usb stick by then.
Launching something like (while sleep 1; do sync; done) & somewhere might help.
/Mads
On Sat, 2010-03-06 at 19:14 +0000, Mads Kiilerich wrote:
J.Heather@surrey.ac.uk wrote, On 03/06/2010 10:42 AM:
The one thing left to sort is the write cache. One of the machines crashed, and one of them lost quite a lot of her work because it hadn't hit the usb stick by then.
Launching something like (while sleep 1; do sync; done) & somewhere might help.
Well, I did wonder about that, or a cron job that runs once a minute. It's something of a kludge, though, and it might make the machine unresponsive.
There must surely be the equivalent of the dirty_writeback setting for vm paging? (That sets how long something can remain in the paging write cache before being written to disk.) It's an obvious thing to have.
James
Time to update you on my little experiments with write cacheing on a live USB stick.
It does look as though I'd misunderstood what the settings in /proc/sys/vm/ are for. I'd taken it that these just controlled paging of virtual memory (hence the 'vm'), i.e., writing to swap. But it seems that they also control the filesystem write cache. So I have stuck with ext4, and I now have in my kickstart:
%post cat >> /etc/rc.d/rc.local << EOF #more aggressive page writing in case of crash or power cut echo 500 > /proc/sys/vm/dirty_expire_centisecs EOF %end
which means that nothing is allowed to remain in the cache for more than 5 sec. (Strictly speaking, it is marked as dirty after 5 sec, and then gets written at the next wakeup, which happens every 5 sec by default; so in fact it can stay in the cache for up to 10 sec.)
Experiments suggest that this works nicely. I just wrote something like
for ((;;)); do date; sleep 1; done | tee logfile
and then yanked the USB stick out and rebooted it to see how much had been written; it wasn't ever more than a few seconds behind the terminal window. The LED also flashed briefly every 5-10 sec, which is what you'd hope.
This does seem more efficient than forcibly syncing every few seconds, which will work, but will also block disk reads during the sync process. It also means that the benefits of delayed allocation don't get seen.
Let's just hope nothing crashes during the real exam and it's all irrelevant!
James
On Mon, 2010-03-08 at 08:07 +0000, James Heather wrote:
On Sat, 2010-03-06 at 19:14 +0000, Mads Kiilerich wrote:
J.Heather@surrey.ac.uk wrote, On 03/06/2010 10:42 AM:
The one thing left to sort is the write cache. One of the machines crashed, and one of them lost quite a lot of her work because it hadn't hit the usb stick by then.
Launching something like (while sleep 1; do sync; done) & somewhere might help.
Well, I did wonder about that, or a cron job that runs once a minute. It's something of a kludge, though, and it might make the machine unresponsive.
There must surely be the equivalent of the dirty_writeback setting for vm paging? (That sets how long something can remain in the paging write cache before being written to disk.) It's an obvious thing to have.
James
James Heather a écrit :
(3) The write cache is good, and makes the whole system feel very responsive, but if a machine crashes or there's a power cut, I'm in danger of them losing lots of work. Is there a way of decreasing the maximum "dirty" time for writes to the USB stick? I have found lots of info on doing this for vm paging, but not for the filesystem itself. All I've found is how to turn off the cache altogether (mount with 'sync'), but that's not an option because everything will run much too slowly. I'd far rather set an option to ensure that everything gets written at most a minute after entering the cache.
Have you already read about "ext4 and data loss"? http://lwn.net/Articles/322823/
livecd@lists.fedoraproject.org
-
Alexander Boström -
J.Heather＠surrey.ac.uk -
James Heather
-
Mads Kiilerich -
Marc Herbert