ISSUE FOUND - ALLOW_OTHER MOUNT - SECURITY PROBLEM in UNRaid?? - DELETE files allowed for any user? HOW CAN THIS BE?

[markhsa]

SEE  SUMMARY HERE:

 

 

Any non root user is being allowed to delete any file under /mnt/user

This is when the file permissions are 444 on that file!?

 

/mnt/user is an array of 4 disks.  Nothing fancy here.  

 

Example:

in /mnt/user

mark@Tuna:/mnt/user$ ls -al testfile
-r--r--r-- 1 root root 0 Dec 22 20:18 testfile
Then....

 

mark@Tuna:/mnt/user$ rm -rf testfile
mark@Tuna:/mnt/user$ ls -al testfile
/bin/ls: cannot access 'testfile': No such file or directory
 

Its gone.

As user mark, I can rm -rf this file?

 

In /tmp Linux permissions are working as expected.

 

How can this unraid array have this happening?

 

Is there some special permissions in Unraid that allow ignoring of standard Linux permissions on filesystems?

 

Very confused.  

 

Any ideas?

 

 

 

 

 

 

Edited December 23, 2018 by markhsa

[trurl]

Unraid isn't meant to be a general purpose linux environment. The Unraid command line and webUI are only meant to be used by the root user. The users you create in the webUI are only for controlling file access over the network. If you need a general purpose multi-user linux environment create a VM.

[markhsa]

That still makes no sense to me.

Here is what started all this.

I installed Plex an Emby.  So that neither could delete files even if they wanted, I set the files for them to read only.

I found that the apps could still delete files though.

How can  I prevent this and protect files if I cant chmod 444 them?

 

What I am asking, I guess, is does Unraid still have standard permissions control?

 

I use this as an unraid server, however, no *nix OS can have this.  

How is this heppening?

 

Are unraid drives not protected as all linux devices/directories are?

 

Or could I have something setup incorrectly?

 

Thanks,

 

Mark

 

[trurl]

Plex has a setting that you can turn off so it won't delete media.

 

Also, have you tried the read-only setting when specifying your docker volume mappings?

[markhsa]

OK, so any docker image has file system access just like a local user would.

As they dont use network file system security, how are docker apps secured then?

 

It sounds like you are saying that in the Unraid file system, permissions are not controled ( only external Network share access ).

Is this correct?  I would be very surprised at this.  This would  mean an unbelievable security issue for any Unraid server for many reasons.  Any local user or exploit would have access to all Unraid share files with no restriction.

 

This would also mean that any docker app would have this same lack of permission control as well.......

 

Are you sure on this?

 

The disks that make the Unraid share are XFS, with BRTFS on the actual shares themsleves correct?  How can there not be security under that?

 

Unraid must support security beyond what the network file share does.

 

Or am I incorrect and Unraid really has this flaw?

 

Thanks for the help.

 

[trurl]

7 minutes ago, markhsa said:

The disks that make the Unraid share are XFS, with BRTFS on the actual shares themsleves correct?

No this is not correct. The disks can have XFS, btrfs or ReiserFS filesystem. There are some vdisks, such as the docker image, which is btrfs. The user shares are just the aggregate of the top level folders on cache and array, and these are just presented as folders and files. Since the disks can have different filesystems a user share could include folders and files from different filesystems.

 

Unraid is designed to allow file access over the network with access controlled by whatever protocol is used, such as SMB. Access to the command line or the webUI is only for the root user. Docker access can be controlled with volume mappings, including options for read-only.

[markhsa]

OK, so can you answer this please?

 

Is there any user file security for local files or for local files that are used by dockers?  Dockers dont use the network controlled access you mention.

 

I understand that SMB is an access method that is used when network share access is used, but with VM's, Dockers, and just general physical access to a server in play, is there really no security?  

 

If this is the case, I hope anyone that has anything on their FS know this.   Very dangerous.

 

Please let me know.  If this is the case, I need to remove any security conscious files ASAP and I suspect others would too.

 

I use Unraid for quite a bit of data, so I really need a thorough answer here please.  If there really is no security unless network SMB/NFS etc. is used, I need to pursue this with the UnRaid DEV team.  How do I do this?

 

Again, I would be so surprised if this type of security hole really exists.

 

Thanks for the time on this.  

 

Its an important question I feel, so please involve devs or others that may have information as well to get a complete answer.

Edited December 23, 2018 by markhsa

[remotevisitor]

The permissions on a file affect whether a file can be read/written ... and deleting a file is neither of those operations.  

 

Rather it is the permissions on the directory containing the file which controls whether a user can delete a file in the directory .... the user deleting the file must have write access to the directory containing the file and execute permission on all parent directories.

 

So you need to be looking at the permissions and ownership of the directory containing the file to be deleted not the permissions on the file itself.

Edited December 23, 2018 by remotevisitor

[ken-ji]

Yes. /mnt/user is a special mount with very weak permissions by default... I wonder if the security here can be tightened up ... but then only plugins would have access at this level typically...

root@MediaStore:~# ls -ald /mnt/user
drwxrwxrwx 1 nobody users 168 Dec 14 21:28 /mnt/user/

 

[BRiT]

Additional Information for the OP:

https://www.tutorialspoint.com/unix/unix-file-permission.htm

 

 

[markhsa]

OK, so there is an issue.

How can a file:

-That is owned by root:root

-Permissions are 444 ( rrr )

 

be deleted by a non root user?  "mark" in this case.  The example in the first post in this issue.

 

No matter where the file exists, no matter what the directory permissions are, this should not be possible in *nix.

Let me know if this is incorrect.  

 

This is what is happening on an MD device created by UnRaid.

 

This is the problem I am seeing.  

[markhsa]

Here is another example of how this is broken.

Full output below.

1) root creates a file called outputfile with content in it.

2) root chmod the file 400 (  no  one can read this file other than root )

3) user "mark" cats the file, it can be read.

 

Permissions on Unraid share are being ignored.  

 

root@Tuna:~# cd /mnt/user
root@Tuna:/mnt/user# echo "test file content" > outputfile
root@Tuna:/mnt/user# cat outputfile
test file content
root@Tuna:/mnt/user# chmod 400 outputfile
root@Tuna:/mnt/user# ls -al outputfile
-r-------- 1 root root 18 Dec 23 10:53 outputfile
root@Tuna:/mnt/user# su - mark
No directory, logging in with HOME=/
mark@Tuna:/$ cd /mnt/user
mark@Tuna:/mnt/user$ ls -al outputfile
-r-------- 1 root root 18 Dec 23 10:53 outputfile
mark@Tuna:/mnt/user$ cat outputfile
test file content
mark@Tuna:/mnt/user$
 

[BRiT]

I suggest you re-read the replies and linked information, specifically about the DIRECTORY permissions.

[markhsa]

In what possible scenario could you cat a file, with no permissions, in the above example and be allowed with ANY directory permissions?

If you know something I dont on permissions, I am open to learn.  So please let me know.

 

[itimpi]

Have you tried using the 'id' command to check what permissions you are actually running as when you tried the 'cat' command.    Since Unraid does not support users other than root logging in it may not be what you expect.

[markhsa]

I have done this.

Results below.

It is a valid user.

It really looks like permissions are being ignored on this unraid mount. 

 

mark@Tuna:/$ id
uid=1002(mark) gid=1002(mark) groups=1002(mark),7(lp),11(floppy),17(audio),18(video),19(cdrom),93(scanner)
mark@Tuna:/$
 

[markhsa]

I cant see how permissions could be ignored in any *nix OS.  But that is what is happening.

The problem comes when  you have dockers, or VM's that use this file system.

 

That means that you cant control read/write reliably or have any security there.  

I cant believe that Unraid could have this type of security flaw.  Something else must be wrong?

[markhsa]

So I suspect this is the problem. 

I wonder if  you all have this mount option on /mnt/user as well?

 

I will test this, but I think this is the mount option that is allowing this and causing this security problem:

 

root@Tuna:/mnt/user# mount |grep /mnt/user
shfs on /mnt/user type fuse.shfs (rw,nosuid,nodev,noatime,allow_other)
 

allow_other is a mount option on this that opens up the security to all.  Very dangerous.

 

From a google:

allow_other This option overrides the security measure restricting file access to the user mounting the filesystem. So all users (including root) can access the files. This option is by default only allowed to root, but this restriction can be removed with a configuration option described in the previous section.

 

Any  thoughts on why UnRaid would use such a gaping security hole?

[markhsa]

I am going to summarize my own post and I have found the issue.  Please correct me where I am wrong here.

 

SUMMARY:

I would consider this a huge security issue in UnRaid.  Do not put any confidential or secure files on UnRaid if you are in the audience below. ( or if you are security aware in my opinion ) 

 

AUDIENCE:

-Anyone running a VM ( Linux, Windows etc.. )

-Anyone with a docker

-Anyone that has access to the UnRaid webgui and the terminal option ( everyone )

-Anyone that has a local user created on the UnRaid server 

 

ISSUE:

If you have dockers or VM's created, OR have any potential local access to your UNRaid server ( terminal from the unraid GUI for instance ) then all files in the /mnt/user ( default ) directory have open permissions.  Anyone can read/write/delete

For me, this would prevent me from putting any secure/confidential files on an unraid directory.  

 

Its true, I also have a local user created on my UNRaid server.  I am an old Unix/Linux guy, so I assumed that UnRaid is a secure server for login.  This NON-PRIVILEGED local user has access to all UnRaid directory files.  Very dangerous in my humble opinion.

 

So, for local users, and dockers, and VM's  ( Plex for instance ) created on UnRaid, your files are wide open for all users to read/write/delete.  Yes,  you can specify that Plex be read-only, but I bet most users are not aware of this need.  VM's ( Linux, Windows etc... ) would have to be considered open and insecure as ANY of the VW files are free to read by anyone with an UnRaid console, or any user that can login to the UnRaid server.

 

CAUSE:

The UnRaid mount is done with an option called allow_other.  This negates security completely on the main /mnt/user mount.

If you execute this on command line:

mount |grep /mnt/user

You will see this below.  
shfs on /mnt/user0 type fuse.shfs (rw,nosuid,nodev,noatime,allow_other)
shfs on /mnt/user type fuse.shfs (rw,nosuid,nodev,noatime,allow_other)

 

I am not aware of an option in UnRaid to change this behavior.  If someone here is aware of this option to change this default behavior, please let me know.

 

 

 

 

 

 

[trurl]

4 hours ago, markhsa said:

Its true, I also have a local user created on my UNRaid server. 

Don't do this.

22 hours ago, trurl said:

If you need a general purpose multi-user linux environment create a VM.

 

I am curious though. Have you tested this with /mnt/disk# instead of /mnt/user? Wondering if this is perhaps an effect (possibly intentional) of fuse.

[markhsa]

Thanks for the followup.

 

A few things on this.

 

1) its unfortunate that you cant use an Unraid server as a Linux terminal host as well.

2) A VM suffers from this security issue as well.  ie. root on Unraid can see all VM file data.

 

Results from /mnt/disk* ( rather than /mnt/user )

 

The behavior is as expected ( correct ) in the /mnt/disk* location. 

The cat command on a file, that a user does not have permission to, is NOT allowed.  Permission denied.

 

This is because the mount options are different:

mark@Tuna:/mnt$ mount |grep disk1
/dev/md1 on /mnt/disk1 type xfs (rw,noatime,nodiratime)
mark@Tuna:/mnt$ mount |grep user
shfs on /mnt/user0 type fuse.shfs (rw,nosuid,nodev,noatime,allow_other)
shfs on /mnt/user type fuse.shfs (rw,nosuid,nodev,noatime,allow_other)

 

The fuse.shfs is the one that has the security issue.

 

My question would be......  As /mnt/user is the aggregated listing of all /mnt/disk* , why is the security different?

 

It seems that /mnt/user is a vitrual user space file system.   Thats OK, however, VM's and docker etc... are advised to use the /mnt/user directory correct?

 

This direction is likely a problem due to this. 

 

Any thoughts on this welcome so that I can understand how to use this better and what the purpose of of the /mnt/user virtual FS is?

 

Thanks,

 

Mark 
 

[limetech]

Create the file 'config/extra.cfg' on the USB flash device with this content:

shfsExtra=-o default_permissions
shfsExtra0=-o default_permissions

These are additional mount options for when /mnt/user and /mnt/user0 are mounted.  They will take affect next time you Start array.

 

To undo these settings, delete the file and then reboot.