Unraid Boot Disk on Linux Filesystem?

[eebrains]

I'm new to unraid.  I've had my rig going with 6.2 for about 5 days now.  I am learning a lot about slackware and unraid - and I like it.

 

Question: Can I install unraid to a boot USB that is formatted in ext2? or ext4?

I don't like that the unraid boot disk (aka /boot/ ) mounts as vfat (ie. 100% open to read/write access), for obvious security reasons.

 

Anyone successfully migrate the boot disk to another format?

 

Thanks

[trurl]

I'm new to unraid.  I've had my rig going with 6.2 for about 5 days now.  I am learning a lot about slackware and unraid - and I like it.

 

Question: Can I install unraid to a boot USB that is formatted in ext2? or ext4?

I don't like that the unraid boot disk (aka /boot/ ) mounts as vfat (ie. 100% open to read/write access), for obvious security reasons.

 

Anyone successfully migrate the boot disk to another format?

 

Thanks

No.

 

Open to read/write access by what or who? You can control access to the boot device with regard to other computers on the network, for example. You can control what you allow dockers and VMs to have access to. Within the unRAID OS itself, everything is running as root.

[eebrains]

I'm new to unraid.  I've had my rig going with 6.2 for about 5 days now.  I am learning a lot about slackware and unraid - and I like it.

 

Question: Can I install unraid to a boot USB that is formatted in ext2? or ext4?

I don't like that the unraid boot disk (aka /boot/ ) mounts as vfat (ie. 100% open to read/write access), for obvious security reasons.

 

Anyone successfully migrate the boot disk to another format?

 

Thanks

Open to read/write access by what or who? You can control access to the boot device with regard to other computers on the network, for example. You can control what you allow dockers and VMs to have access to. Within the unRAID OS itself, everything is running as root.

Example:  I forward SSH over port X from my router to port Y on my unraid box.  If my unprivileged user account is compromised via ssh (after all, passwords are sent in the clear), then said account would instantly have free will on my /boot/ directory.  For that matter, everything in /mnt/ is also 777.  Before I get the obvious "don't forward ssh to your router", I do understand the risk - so I have disable password auth and use only publickey auth.

 

Perhaps there is a way to set up the initial mounting options somewhere to restrict ownership of /boot and /mnt... If the system is operating as root, then it wouldn't cause ownership issues, right?  I know that FAT32 can't control ownership of individual files, but you can mount the device with specific ownership applied recursively to the mount point.  Would there be a (safe) way to do this?

[itimpi]

There is no unprivileged account on unRAID in the normal Linux/Unix sense.  Accounts other than 'root' are only used to control access to shares.

[eebrains]

Lets say I have created a user eebrains on my unraid box.  I can set up ssh keys to eebrains.  This user cannot perform actions as root without the root password.  Sorry if "privaleged" means something else, I'm not up to speed with lingo yet.

 

If the user eebrains is logged in, they cannot write to anything they do not own, or have group/public permissions.

 

I want to know if it is possible to change the permissions of /boot/ to be root owned, unwritable by others (ie 755).  This would have to occur at the time of booting obviously.

[gubbgnutten]

Except that user eebrains would normally not be able to log in...

[trurl]

The unRAID "Users" are just for network file access with SMB or NFS or AFP. Only root has command line access.

[eebrains]

The unRAID "Users" are just for network file access with SMB or NFS or AFP. Only root has command line access.

Yes, yes, yes.  I get that its easy to get hung up on that...  So I configured a non-root user with ssh key access so I can remote in without accessing root directly.

 

Anyhow, nobody has addressed the actual question about changing default mounting permissions of /boot...

[gubbgnutten]

Maybe look into running a VM to provide remote shell access and whatever you need rather than messing with the base system?

[trurl]

The unRAID "Users" are just for network file access with SMB or NFS or AFP. Only root has command line access.

Yes, yes, yes.  I get that its easy to get hung up on that...  So I configured a non-root user with ssh key access so I can remote in without accessing root directly.

 

Anyhow, nobody has addressed the actual question about changing default mounting permissions of /boot...

Why do you want to do this? If you just want a linux to play in create a VM like gubbgnutten suggested.

[Squid]

Anyhow, nobody has addressed the actual question about changing default mounting permissions of /boot...

You can set the permissions for /boot separately over the network.  Don't export, export hidden, export, certain unraid users no access or read-only, or read-write.

[trurl]

It occurs to me that you may not understand what the boot disk actually is. It is not actually the operating system. It just has the operating system archive on it. unRAID unpacks the OS fresh on each boot from bzimage,bzroot. It unpacks it into RAMfs, and the operating system files are completely in RAM. Other than those archive files, the rest of it is just configuration files that store settings you make in the webUI. The boot disk is seldom accessed except for bootup and to read and write those settings.

[gubbgnutten]

It occurs to me that you may not understand what the boot disk actually is. It is not actually the operating system. It just has the operating system archive on it. unRAID unpacks the OS fresh on each boot from bzimage,bzroot. It unpacks it into RAMfs, and the operating system files are completely in RAM. Other than those archive files, the rest of it is just configuration files that store settings you make in the webUI. The boot disk is seldom accessed except for bootup and to read and write those settings.

 

Still, giving a random (possibly hostile) user write access to /boot would be a really really bad idea from a security point of view. Lots of potential for mischief.

[ken-ji]

It just occurred to me that some of the OP's points are valid regarding the world writable mounts, but I guess unRAID's design is simply: low level shell access is supposed to be root only. No other user. Thus the permissions don't really matter. or rather this will allow network users to access any of the files - as long as the file access protocol (SaMBa, NFS, etc) allows it. But with the inclusion of dockers and VMs, you now have low level shell access granted to an arbitrary user, (ie the one running the dockerized app) that may or may not be restricted in the intended sense.

 

 

I think, the OP shouldn't be granting his user account shell access to unRAID directly, but rather to a Linux VM, which could server as a bastion host to mitigate some disasters, like accidentally/maliciously nuking the USB drive via the /boot mount. Also, it should be possible to make a SSHd docker, which would give him a jump point to access from the outside, then access unRAID from there.

 

 

just my 2 bits.

[eebrains]

One reason I was set up to ssh remotely to the main system was to get plex running.  I use plex-pass verison, and I am not yet familiar with docker (but will be someday soon).  Anyhow the simplicity of Slackware packages makes it so easy to install plex natively... I was up an running in minutes.

 

Now... I think I learned why not to do that...  Another mistake - I had set up my array drives formatted as btrfs (thnking ahead to integrated snapshots).  One of my shares was completely hanging on disk access due to some bad metadata checksums (presumably from plex running without the array online).  So I nuked my array last night (I'm backed up), and started over. 

 

Today just for kicks I reformatted the USB to ext2, labeled it UNRAID.  Copied everything I needed to it, and ran the install script.  Rebooted... yep it doesn't work!  I figure it failed because the default mount configuration assumes "-t vfat"... so no dice.  I was doing it all remotely so I'll have to check it when I get home.

 

Looks like I'll have to learn more about docker... but I definitely want to be able to do tweaks on my system from the shell.

 

Thanks guys.

[wgstarks]

Looks like I'll have to learn more about docker... but I definitely want to be able to do tweaks on my system from the shell.

 

Thanks guys.

Docker is super simple. I installed the linuxserver-io plex docker from CA and just had to add file paths to movies, tv, etc. All the Linuxserver-io dockers have great support.

[IGHOR]

There is risk of SMB/AFP/etc protocols hack anytime and it will give possibly to edit /boot/config/go file by any user. It is equal to full root rights on next reboot. 

Is there way to boot SysLinux from ext4 partition?

 

 

[JonathanM]

26 minutes ago, IGHOR said:

Is there way to boot SysLinux from ext4 partition?

Not at this time. The OP in this thread asked the exact same question for the exact same reason, and it was thoroughly discussed. Did you read the thread?

[IGHOR]

Not at this time. The OP in this thread asked the exact same question for the exact same reason, and it was thoroughly discussed. Did you read the thread?

Yes. It have been 1.5 years passed so I decided to ask again. No changes is bad news.

[JonathanM]

If an exploit in one of the named protocols was found, the attacker would have to target the attack to the unraid system, and would have to be local to the network or have exploited another device inside the network. The probabilities of this happening are pretty remote, given the publicity an exploit on those named protocols would generate. If that were to happen, simply disabling the network access to the flash share should be sufficient to mitigate the risk.

 

The point of having the flash drive as FAT is so you can create, edit and make changes from practically any OS natively instead of being forced to load tools or jump through hoops. It's a very small risk compared the the support issues created if you couldn't pop the USB stick in another box and edit the config files in case of user induced misconfiguration that keeps the stick from working properly.

 

Unraid is NOT hardened, and should be treated as a soft target. Ease of use for the inexperience hobbyist takes priority over industrial hardening. Where changes can be made to help secure it, they are considered and implemented if practical. Great progress has been made on that front, but the low probability risks are low priority.

 

If you encrypt your data drives as is now supported, the array won't allow access to your data without the key. Changing the files on the USB stick to be implemented on next boot won't change that.

[IGHOR]

If an exploit in one of the named protocols was found, the attacker would have to target the attack to the unraid system, and would have to be local to the network or have exploited another device inside the network. The probabilities of this happening are pretty remote, given the publicity an exploit on those named protocols would generate. If that were to happen, simply disabling the network access to the flash share should be sufficient to mitigate the risk.   The point of having the flash drive as FAT is so you can create, edit and make changes from practically any OS natively instead of being forced to load tools or jump through hoops. It's a very small risk compared the the support issues created if you couldn't pop the USB stick in another box and edit the config files in case of user induced misconfiguration that keeps the stick from working properly.   Unraid is NOT hardened, and should be treated as a soft target. Ease of use for the inexperience hobbyist takes priority over industrial hardening. Where changes can be made to help secure it, they are considered and implemented if practical. Great progress has been made on that front, but the low probability risks are low priority.   If you encrypt your data drives as is now supported, the array won't allow access to your data without the key. Changing the files on the USB stick to be implemented on next boot won't change that.

 

 

 Thanks for detailed explanation. If I encrypt disks and someone get access to edit config/go, on next reboot I may not know that it is hacked and I’ll enter key for disks via web. So disk encryption gives same level of security as no encryption if /boot available for r/w. And they will easily grab /root/keyfile anyway. At least we need notification that usb disk was modified not by unRAID services itself for manual review. Looks like unRAID’s disk encryption is only helps to prevent data leaking if someone steal your machine. But keyfile stored in RAM as plain text, so if someone really want to get access to your disks, they maybe can find the way to dump physical RAM and easily copy keyfile.

 

To make unRAID secure I have to create all shared folders inside of Docker instances.

 

 

[IGHOR]

I have Raspberry Pi, it boots from FAT32 partition that mounted to /boot

I can't edit /boot content with user, only under root. Why it not works the same on unRAID?

How can I set the same restrictions for /boot folder as on any linux booted on Raspberry Pi?

Edited May 26, 2018 by IGHOR

[IGHOR]

cat /etc/fstab | grep boot
/dev/disk/by-label/UNRAID  /boot         vfat      auto,rw,exec,noatime,nodiratime,umask=0,shortname=mixed  0  1

 

Here is umask set to 777, and should be 755 instead.

 

There should be no reason to mount /boot with 777 rights.

Edited May 26, 2018 by IGHOR

[itimpi]

It is intentional that the /boot partition should be accessible and editable over the network (for those that want to expose it as the ‘flash’ share).  Changing the permissions like you mention would make this impossible, and raise the support burden on Limetech.   I think the trade-off would be seen as not worth it.  I know I personally often want to change items on the flash drive over the  ‘flash’ network share rather than having to open up the server to access the USB drive (with the associated risk of disturbing cables).  There are likely to be implications elsewhere as well in making it harder to store configuration information on the USB drive.   I am also not certain it provides much improvement in security, especially as unRAID does not have users in the traditional Linux sense.

 

having said that you are welcome to try and make a strong enough case to convince Limetech otherwise.

Edited May 27, 2018 by itimpi

[IGHOR]

5 hours ago, itimpi said:

...especially as unRAID does not have users in the traditional Linux sense...

 

Yes, it does works same way. You can create user via web interface, enable SSH via web interface and login to SSH with new user.

You will get read only access to root filesystem, except /boot

SFTP works fine that I prefer to use it instead of SMB/AFP share for usb disk editing, also you can edit all configs via web.

I would like to make web interface accessible only from localhost, use port forwarding via SSH to 127.0.0.1:80 and access web interface this way.

Local networks are not secure if there is lots of users with different OS, with uncontrolled access.

There should be option to set rights for /boot to 755, because it requires very small changes.

Edited May 27, 2018 by IGHOR