is a data partition best mounted with NOEXEC & NOSUID?

[linx255]

Hi, I'm using Mint 17 Mate 64-bit.

I read that it's best to mount a data partition with NOEXEC and NOSUID parameters so that nothing can execute. Does this really make my machine safer though? What if I want to store my scripts on that partition? Does that mean I wouldn't be able to execute them? Just trying to understand what these options mean.

What about applying NOEXEC / NOSUID to the home folder? Someone recommended doing this, but is this really necessary?

Thanks

[xenopeek]

What these do is explained in the mount manpage (man mount). Look at your currently mounted partitions, you'll find a whole bunch mounted as nosuid, nodev and optionally also noexec:

Code: Select all

mount | column -t

Yes noexec things make your computer safer, as for example when you say "this is a data partition" then if you download something that masquerades as data but actually is a malware script or binary--you won't be able accidentally launch it. Any non-root partition you should mount as nosuid and nodev, as there is no reason to allow those on non-root partitions. It is a security risk to allow them, however remote it may be. Hence most of the filesystems you see in the mount output are nosuid and nodev. noexec makes sense for all filesystems where you won't want to put executables.

[altair4]

Think of the ramifications of what would happen if you implemented these options.

"exec" doesn't force everything to be executable it simply allows the user / systems admin to make something executable.
nosuid disables the setting of the sgid bit which is one of the classic ways of creating a multi-user shared directory that is writeable to a given group of users.

Neither noexec or nosuid seem fitting for something called a "Data" partition.

[linx255]

I didn't find any info in 'man mount' page of any use. ( Please be patient with me, I occasionally find man pages useful; they are too often cryptic and decontextualized. I've spent the last decade learning Linux and I still don't know jack. My knowledge is more well-rounded and broad / general than deep and nitty-gritty. I know how to do a whole lot of cool basic things but my understanding of the Linux conventions is a bit clouded. Just now getting into all this! I read up on wikipedia but couldn't find the answer to my question there either. Actually, the wikipedia articles led to my question. )

None of my partitions are set to noexec, though quite a few folders are. Only my /boot partition ( /dev/sda1 ) and the extended partition ( /dev/sda2 ) that hosts all my other logical partitions are set to nosuid. My logical paritions are /dev/sda5,6,7, & 8, which are 3 bootable OS partitions and a data partition.

I can understand wanting to avoid accidentally running a malicious program masquerading as something else. I pay very careful attention to what I download, and from where, but if I don't trust the source I won't be downloading it in the first place. I hardly ever download anything except from trusted sources. I suppose as a precaution I should check the file attributes of downloaded files and make sure what's supposed to be a normal text file isn't a bash script marked as executable. But I routinely launch my own bash scripts from my data partition and definitely do not want to prevent their being launched or have to relocate them to my root partition where disk space is more limited and the data would be vulnerable to OS crash. The reason I made the data partition was to keep my data separate from the OS. I also want to retain the ability to enable or disable executable attribute. My data partition is not a "multi-user shared directory" at this point, or is not supposed to be, and I don't expect it will be unless I later decide to implement my system as a kind of server for an office setting. Should I turn off nosuid on my data partition for now?

[xenopeek]

Mount with nosuid and nodev. As I said, noexec is optional and don't use that if you want to be able to run files from the filesystem you are mounting.

As for "multi-user shared directory", I don't quite know that either. As I take it, you achieve that by setting permission mode similar to /tmp (1777). In /tmp all users can read, write, and execute files -- but they can only delete files they themselves put there.

[linx255]

you achieve that by setting permission mode similar to /tmp (1777)

This I have done in my /etc/fstab, but I don't remember why I did this, but it wasn't to setup a multi-user anything.

I think I'll not use noexec on my data partition then... Now setting data partitions to mount with nosuid and nodev.

[altair4]

As for "multi-user shared directory", I don't quite know that either. As I take it, you achieve that by setting permission mode similar to /tmp (1777). In /tmp all users can read, write, and execute files -- but they can only delete files they themselves put there.

Nope. Well, in fairness it depends on your definition of "write".

If I set a folder to 777 then everyone and your Aunt Tilly can add to the folder. If that is your definition of write then you are indeed correct.

If however aunttilly add a file to the folder it will save as owner=group=aunttilly with permissions of 664. Aunt Tilly can edit the file but no one else can. For that you need the set gid ( or sgid ) bit ( as in 2775 ) which forces every new file / folder added to "inherit" the group of the parent and everyone you want to have that ability has to be a member of that group. This is used in local multi-user shared directories, Samba, plexserver ( I think ), and other things.

[xenopeek]

Ah! Thank you for explaining.

[linx255]

the mount manual says:

noexec = Do not allow direct execution of any binaries on the mounted filesystem

So if noexec is set does this mean that shell / python scripts / other non-binary programs can still execute from there? By "binaries" do they mean "compiled"?

[eanfrid]

noexec means that executables will have to be explicitely invoked as parameters by an external program (interpreter) to be run. For instance, "whatever.sh" cannot be run from a noexec mountpoint even if the executable bit is positioned on the file, however if you run "sh whatever.sh", the script will execute, regardless of the presence of either noexec or executable bit.

nosuid will only prevent executables to run with suid/gid impersonating rights (possible privileges escalation) while the setgid bit will still apply on folders.

At last when you download a file in your home, even an executable, the executable bit is never positioned then no downloaded file is actually ever executable without a voluntary manual intervention. So noexec is less useful than nosuid regarding permissions-oriented security and mostly only makes sense if you use nosuid with noexec.

[altair4]

nosuid will only prevent executables to run with suid/gid impersonating rights (possible privileges escalation) while the setgid bit will still apply on folders.

You are quite right. In fact my example of using sgid on a directory to achieve a multi-user writeable directory doesn't even work in Mint.

This is what happens in Xubuntu or any other Ubuntu derivative:

tester1@vxub1404:~$ sudo mkdir /DataL/Test
tester1@vxub1404:~$ sudo chown :plugdev /DataL/Test
tester1@vxub1404:~$ sudo chmod 2770 /DataL/Test
tester1@vxub1404:~$ touch /DataL/Test/test.txt
tester1@vxub1404:~$ ls -al /DataL/Test/test.txt
-rw-rw-r-- 1 tester1 plugdev 0 Jul 22 07:35 /DataL/Test/test.txt

The added file "inherits" the group of the folder. Since the default umask is 0002 the resulting permissions are 664 making it editable by every member of that group.

This is what happens in Mint:

tester1@vm17-0cin ~ $ sudo mkdir /DataL/Test
tester1@vm17-0cin ~ $ sudo chown :plugdev /DataL/Test
tester1@vm17-0cin ~ $ sudo chmod 2770 /DataL/Test
tester1@vm17-0cin ~ $ touch /DataL/Test/test.txt
tester1@vm17-0cin ~ $ ls -al /DataL/Test/test.txt
-rw-r--r-- 1 tester1 plugdev 0 Jul 22 07:32 /DataL/Test/test.txt

The added file does in fact "inherit" the group of the parent folder but the file saved has permissions of 644 rendering it un-editable by the members of that group.

The difference between Mint and the OS it's derived from appears to be because Mint's display manager breaks umask: pam_umask USERGROUPS_ENAB option broken

[linx255]

I think I follow, but I need more clarity please.

...invoked as parameters by an external program (interpreter)....."whatever.sh" cannot be run from a noexec mountpoint...however [it will be allowed to execute via sh]...

"Invoked as parameters" as opposed to what? I don't understand what you mean by these terms.

I always though of 'sh' was an interpreter. What constitutes the external / internal program distinction? Sh being built-in the kernel as opposed to some other interpreter? Do you mean it will only run depending on whether the point of initialization was mounted as noexec or not? ( I.e. If I cd into a noexec / exec drive and initialize the program from there ) Or do you mean whatever.sh can only be executed depending whether that script is stored on a noexec / exec mountpoint or if the external program is stored on a noexec / exec mountpoint?

no downloaded file is actually ever executable without a voluntary manual intervention

However, a downloaded file such as an archive, could contain files with executable permissions and be extracted with permissions intact if tar is run as superuser. Of course, invoking superuser could be considered a sort of a voluntary, manual intervention.

So noexec is less useful than nosuid regarding permissions-oriented security and mostly only makes sense if you use nosuid with noexec.

Why exactly is it best to use them together? I have my data partition set to mount with nosuid, but not noexec because I still need to be able to run scripts stored on it. They could be launched from anywhere: the desktop panel or a terminal cd'd into one drive or another. I haven't decided whether I want to run scripts with sh, bash, or dash yet. Basically, I just want to safely run scripts stored on my data partition and don't want any script stored there ever initialized without me having something to do with it, so I have to make decisions about how to mount my data partition and how &/ from where to run my scripts.

Thanks for all the helpful examples.

[xenopeek]

"Invoked as parameters" as opposed to what? I don't understand what you mean by these terms.

I can answer that one. With a partition mounted with noexec you can't do this:
- Double-click an executable file on the partition in your file manager to start it, noexec blocks this;
- From the terminal start an executable file on the partition with a command like "./myscript.sh", again blocked by noexec.

What you can still do:
- Invoke a script interpreter yourself and tell it to run the contents of an executable text file, with a command like "sh myscript.sh".

Why can you do that last one? Because now you are directly invoking the interpreter, and telling it to read commands from a text file. The interpreter isn't on the partition with noexec, so it can run. The file you tell it to read commands from is readable, so noexec has no effect. You can always run the contents of a readable text file in an interpreter this way; the text file doesn't need to be executable.

[eanfrid]

@xenopeek: thanks to have taken time to explain more extensively what I thought having made clear.

@linx255: by personal choice, I always mount data partitions with noexec,nosuid,nodev and never met any problem with that. So to answer your topic title question, yes it is safer than the default mount options but this is not bulletproof.

and be extracted with permissions intact if tar is run as superuser. Of course, invoking superuser could be considered a sort of a voluntary, manual intervention.

it is then even resorting to a manual act of the local god: root

[linx255]

@xenopeek:

The file you tell it to read commands from is readable, so noexec has no effect. You can always run the contents of a readable text file in an interpreter this way; the text file doesn't need to be executable.

Ok, so it sounds like it's mainly just used to keep oneself from unintentionally running executables. I'm such a newb to the ancient art of permissions but now it all makes sense.

@eanfrid:

"local god: root"