Tiny Core Linux
Tiny Core Base => TCB Talk => Topic started by: andyj on May 31, 2013, 03:04:32 PM
-
I've looked through the scripts in the /etc directory and I see where it's added to fstab, but I can't find the actual mount anywhere. If I were to add ro to the mount options in rebuildfstab it would affect everything it finds. I could remount it ro, but I would rather it be ro from the start. Removable media still needs to be writable.
Andy
-
Hi andyj
I would add a command to /opt/bootlocal.sh to remount the drive read only.
-
I thought about that, but I still say the right way is to make it RO from the start. If I find it I will figure out how to make it a kernel command line option for all to use.
Andy
-
I could remount it ro, but I would rather it be ro from the start.
It is far from clear what your issue is.
What exactly is holding you back mounting ro from start?
-
Where is the mount command for /mnt/sda1 in the boot process, so I can fix it?
Andy
-
Fix what exactly?
Are you talking about a partition getting automatically mounted at boot?
-
If your tce directory contains loop mounted extensions, you cannot mount it read only.
The only partitions that are automatically mounted at boot are partitions that contain tce, opt, or home.
These cannot be remounted read only.
You can use the copy2fs flag to ensure that there are no loop mounted extentions.
You can then remount the partition containing the tce directory read only.
Ex: mount -oremount -r /mnt/sda2
This line can be entered in /opt/bootlocal.sh
Other partitions must be manually mounted, or mounted in bootlocal.sh.
Ex: mount -r /mnt/sdb2
-
The TCE dir is mounted in /usr/bin/tce-setup. It's an easy two line update. This would make a nice enhancement for systems which use read only media like CF cards with write protect switches. Then just change tce to tcero in syslinux.cfg / extlinux.conf.
--- /usr/bin/tce-setup
+++ tce-setup
@@ -19,7 +19,7 @@
if [ "$MOUNTED" == "yes" ]; then
setupExtnDirs
else
- mount "$MOUNTPOINT"
+ mount "$MOUNTPOINT" $TCERO
if [ $? == 0 ]; then
UMOUNT="yes"
setupExtnDirs
@@ -125,6 +125,7 @@
for i in `cat /proc/cmdline`; do
case $i in
tce=*) TCE=${i#*=} ;;
+ tcero=*) TCE=${i#*=} ; TCERO="-o ro" ;;
lst=*) TARGETLIST=${i#*=} ;;
esac
case $i in
Andy
-
If I understand right, then you would end up with a read-only TCEDIR, when it is a requirement for TCEDIR to be writable.
I think the reason cde was introduced was to avoid that.
-
Clean ways to prevent a partition from being mounted rw would be:
1. boot code "base"
2. mv /tce
3. see Reply #6
-
All of those have problems:
1. What is the requirement that the TCEDIR be writable? If you WANT to make changes then it NEEDS to be writable, but if you don't want anyone to make changes, then I don't see any reason why it must be writable.
2. There is nothing in the CDE mount command that forces it to be read-only. It must be assumed that if you are using this then the media already is. This would have to be fixed.
3. The base option doesn't mount the tce dir so that the extensions can be loaded
4. Move tce to where? CF cards are detected and mounted as sda1, which is automatically assumed to be writable. This isn't always true, and needs to be addressed.
Andy
-
2. There is nothing in the CDE mount command that forces it to be read-only. It must be assumed that if you are using this then the media already is. This would have to be fixed.
I don't think there is any explicit requirement for CDE to be read-only, but purpose of CDE being that a read-only dir would not become TCEDIR, i.e. to allow CorePlus with default mode.
4. Move tce to where?
mv /tce /tce.moved
-
My system has no CD drives, so /etc/sysconfig/cdroms would be empty and CDE would do nothing. What does moving tce accomplish? The goal is to have the boot media mounted read only, even if it is physically writeable.
Andy
-
There is no mechanism for the boot medium to be automounted, in fact the boot medium could be detached immediately after the bootloader has loaded kernel and initrd's into RAM.
-
Unless "nofstab" is specified in cmdline, disk devices will be added to the fstab, and the device tce is on will be mounted unless "base" is specified. If one does specify "base" then how do extensions get loaded?
The original design was a PXE setup, so this wasn't an issue. The machines for this project aren't on that network, so they need to boot locally. I've looked through the boot process, and there just isn't a clean and easy way to have a read only system booting from a local hard disk, flash card, or USB stick. There needs to be one.
Andy
-
Cut yourself a second initrd with the change you want.
-
I did that already. That's how I know it works. I posted the patch with the hope that others would see the utility of a read only option so it could be incorporated in the main line, but it looks like I'm the only one building embedded industrial systems.
Andy
-
Unless "nofstab" is specified in cmdline, disk devices will be added to the fstab, and the device tce is on will be mounted unless "base" is specified. If one does specify "base" then how do extensions get loaded?
TCEDIR defaults to /tmp/tce.
Optionally 'tce-setdrive' can be invoked.
-
I posted the patch with the hope that others would see the utility of a read only option so it could be incorporated in the main line, but it looks like I'm the only one building embedded industrial systems.
Feature requests or suggestions are fine, but fall in the competence of the team.
To me that sounds like an additional mode.
All answers given in this thread were based on current system design.
-
Yes, a ro option sounds good. I would prefer having it as an additional flag and not a tce= replacement.
But adding it does need to take into account that it would prevent any changes. Even with sufficient warnings, what would be the chance that someone tells new users to use it in some tutorial, and then we get posts about how nothing works.
Even now many third-party installers have a bad set of default bootcodes, causing issues for users. I can imagine how one of the installers' authors sees this, decides "hey, our target is USB sticks, read-only is good", and user complaints multiply.
-
Hi curaga
Even with sufficient warnings, ...
You could set up the flag like this:
ro=I_have_only_myself_to_blame_if_this_does_not_work
-
But when remasters are posted and other unsuspectingly download it and find many tce programs do not work. Folks we have been here before, and that is what lead to the cde directory.
-
I agree that adding this option would have to be a conscious result of editing the boot config file, as it would have the effect of welding the doors shut. In testing I can mount a virtual disk into the host file system or put a CF card into a reader on another system, but unless a person had another way to physically access the drive like booting from another partition or a usb stick it would be the last thing they ever do on the box. The cde route doesn't accomplish what I'm trying to do, and as I said before it would mount the device rw if it could because the ro option isn't used in it's mount command in tce-setup.
I tested with a separate option initially, so that would work too. I changed it to "tcero" to try to reign in the number of cmdline options. Later on I thought about the other stuff I would like to do, wherein not only is the boot device locked out from writes but maybe disabling things like interactive logins, accessing removable media, ctl-alt-del, X xap, VT switching, etc. I see the choices as:
1. A separate cmdline option to set a "lockdown" mode. A one size fits all, which probably isn't what anybody wants.
2. Separate cmdline options for each lockable option. Could become unwieldy and ugly.
3. A separate initrd with a new "/etc/sysconfig/lockdown-options" file that the boot scripts could look for and in.
4. A separate initrd with the appropriate files patched. Becomes locked to the version it was developed from unless some hooks are put in place.
5. A Wiki HOWTO for #4. Everyone would have to invent their own wheels. Mileage would vary, which would drive up the number of questions.
6. Put in some hooks to help with #4 and #5 above.
7. Some combination of the above.
I wouldn't mind doing some lifting if there was a consensus on the design.
I don't know how to help with people asking about help with a broken remaster. Maybe if there was some sort of TC genuine advantage program...
Andy
-
Later on I thought about the other stuff I would like to do, wherein not only is the boot device locked out from writes
Note that there is no way for Linux to determine the boot device.
-
If they can get a command prompt, they can remount the device read-write.
The only useful change I can see would be to change the system to mount the CDE directory read-only, but
still won't stop someone with a command prompt.
-
Technically yes, the kernel wouldn't have any way to know how it got loaded into memory unless whatever put it there left some sort of clue. The system designer knows which is the boot device and can configure based on that knowledge. In a lockdown mode I would I just use ro for all scsi devices to be safe. For the most flexibility, a boot option could be something like "ro=sda1" or "ro=sda1,sdb1" or "ro=all".
If a person can get a command prompt then you're already pwned. This is why I listed the other possible restrictions in my last post.
Andy
-
Speaking of clues
In resolving the path to a booted device I create a file named with a ten digit (random) number which is previously stored for example at the root of a remastered ISO. On boot a script runs from bootsync which mounts all devices, searches for that specific number and captures the path using find and sed. The captured path is useful for other tasks but initially adds an exception to umount allowing all other non booted devices to be unmounted.
I find that technique quit useful when booting one device amongst many possible drives
-
Why not use blkid and the UUID or LABEL ?
-
Absolutely in fact LABEL is highly flexible, works better than expected across many devices (except CD's), whilst UUID offers considerably less flexibility being unique to only one device. Now that I've been introduced to volume label boot codes I use a LABEL with waitusb=5:LABEL=MY_UNIQUE_LABEL boot code exclusively to assist the boot process on my personal devices. However there are utilities out there which do not respect a LABEL when writing an ISO to USB thumb stick, indeed may even write their own which defeats the purpose.
Seeding the ISO with a unique identifier file will ensure the script can find and copy my files to the home dir. after the boot process is complete. This technique along with some predictive reasoning can find my files and begin copying them seamlessly within milliseconds.
Didn't want to dilute this thread, was just agreeing with Andyj that a clue can be used effectively.
-
Now that I've managed to lock TC down somewhat, I've learned that it will take most of the methods I outlined earlier. While inittab is unlikely to change between TC versions and so can be reasonably be safely included in an additional initrd, the same cannot be said for tce-setup. I would still like to see a "mount tce drive read only" kernel command line option. I can live with different configuration files from the mainline since that's why they exist, but I don't like the idea of having to patch code.
Andy
-
I think you are putting too much trust in read-only.
If it is locked down, why do you need read-only.
If it is not locked down, the user can remount it read-write.
If you are worried about someone changing boot options you can boot off sda1 and have your TCE=sda2.
This way the boot partition won't be mounted at all.
It still won't stop a determined user with a shell that can obtain root privileges.
--- edit ---
You can also use chattr to make directories and files immutable.
-
I'm doing plenty of other things too:
Xorg.conf:
Option "DontVTSwitch" "true"
Option "DontZap" "true"
inittab:
tty1::once:/sbin/getty -nl /sbin/autologin 38400 tty1
::ctrlaltdel:/bin/true
.profile
nohup startx >/dev/null 2>&1 &
.xsession:
$(grep -q nosuders /proc/cmdline) && sudo sed -i -e 's/^tc/#tc/' /etc/sudoers
There is no window manager loaded, and Xprogs.tcz isn't loaded either. Because getty runs once, startx keeps running after the shell exits, the three-finger salute is disabled, VT switching is disabled, X zapping is disabled, and su is disabled getting to a session with privs will be hard. Oh, and there's no keyboard either, just a touchscreen.
Making it read only is just part of locking it down. I like the chattr idea, but this is a FAT32 file system so it's not an option for this project.
Andy