Bug 241684 - autofs: no way to have permissions other than 755 for automounted media
Summary: autofs: no way to have permissions other than 755 for automounted media
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 11.3-RELEASE
Hardware: Any Any
: --- Affects Some People
Assignee: Edward Tomasz Napierala
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-11-03 08:56 UTC by Victor Sudakov
Modified: 2020-01-05 17:50 UTC (History)
4 users (show)

See Also:


Attachments
mount_msdosfs hack (2.61 KB, patch)
2019-12-14 15:25 UTC, Jason W. Bacon
no flags Details | Diff
Header to go with patch (146 bytes, text/plain)
2019-12-14 15:25 UTC, Jason W. Bacon
no flags Details
Generalized default options hack (3.79 KB, patch)
2019-12-22 15:16 UTC, Jason W. Bacon
no flags Details | Diff
Patch to allow custom mount flags via special_media (2.26 KB, patch)
2020-01-05 17:26 UTC, Jason W. Bacon
no flags Details | Diff
Example msdosfs customization script (1.06 KB, application/x-shellscript)
2020-01-05 17:28 UTC, Jason W. Bacon
no flags Details
Replace printfs from testing with logger (2.36 KB, patch)
2020-01-05 17:50 UTC, Jason W. Bacon
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Victor Sudakov 2019-11-03 08:56:01 UTC
When automounting removable media via the -media map, there is no way to specify filesystem permissions to the subdirectories of /media other than the default "drwxr-xr-x root:wheel" which prevents unprivileged users from writing to the removable flash drives etc. Permissions of the /media directory are not being inherited.
Comment 1 Edward Tomasz Napierala freebsd_committer 2019-11-25 13:50:08 UTC
When you mount a filesystem, permissions on a mountpoint are taken from permissions from the mounted filesystem root directory.  Basically:

% ll
total 6
drwxr-xr-x   3 root  wheel   512 Nov 25 13:04 .
drwxr-xr-x  23 root  wheel  1024 Nov 25 13:04 ..
drwxr-xr-x   3 root  wheel   512 Nov 25 13:44 md0
trasz@v2:/media % ll
total 6
drwxr-xr-x   3 root  wheel   512 Nov 25 13:04 .
drwxr-xr-x  23 root  wheel  1024 Nov 25 13:04 ..
drwxr-xr-x   3 root  wheel   512 Nov 25 13:44 md0
trasz@v2:/media % cd md0 
trasz@v2:/media/md0 % ls -al
total 9
drwxrwxrwx  3 root  wheel     512 Nov 25 13:47 .
drwxr-xr-x  3 root  wheel     512 Nov 25 13:04 ..
drwxrwxr-x  2 root  operator  512 Nov 25 13:46 .snap
trasz@v2:/media/md0 % cd ..
trasz@v2:/media % ls -al
total 9
drwxr-xr-x   3 root  wheel   512 Nov 25 13:04 .
drwxr-xr-x  23 root  wheel  1024 Nov 25 13:04 ..
drwxrwxrwx   3 root  wheel   512 Nov 25 13:47 md0

In this case, "ls -al" triggered mounting an UFS-formatted md0, which, before the experiment, had "chmod 0777 ." done to its root inode.

What I'm getting at - the permissions on autofs nodes shouldn't matter at all; it's the mounted filesystem's permissions that's being used for the access checks.  Could you tell me some more about your scenario?
Comment 2 Victor Sudakov 2019-11-25 14:00:45 UTC
(In reply to Edward Tomasz Napierala from comment #1)

> When you mount a filesystem, permissions on a mountpoint are taken from permissions from the mounted filesystem root directory.

What permissions are there in the root directory of an msdosfs or exfat filesystem? None. Those filesystems don't support permissions. Therefore those filesystems inherit permissions from the directory they are mounted on (man mount_msdosfs for -m).

> Could you tell me some more about your scenario?

Try to mount an msdos-formatted flash card (from your camera) by autofs, in a way that unprivileged users could write to it, and you'll see my point.
Comment 3 Edward Tomasz Napierala freebsd_committer 2019-11-25 15:19:53 UTC
Okay, now I understand what you mean (for the record: code block at mount_msdosfs.c:202).  Again, just like with charsets, the right way would be to set those in auto_master (eg '/media          -media          -nosuid,noatime,autoro,-M=777,-m=666') or modify /etc/autofs/special_media.  I don't we should add permissions support to autofs; it would be hacking around a hack in msdosfs.
Comment 4 Victor Sudakov 2019-11-25 15:44:11 UTC
(In reply to Edward Tomasz Napierala from comment #3)
> just like with charsets, the right  way would be to set those in auto_master 

No, this will break exfat because fuse does not understand the -M and -m options, and /media is common for both msdosfs and fusefs. Won't do.

> or modify /etc/autofs/special_media

What modifications to /etc/autofs/special_media do you suggest? I guess the stock /etc/autofs/special_media map should provide for group- or even world-writable mounting of removable media. At least that is what users expect: you insert your SD card and then you write to it, or delete files there.
Comment 5 Victor Sudakov 2019-11-25 16:59:10 UTC
I think "-M=777,-m=666" should be the default for _fstype=msdosfs
Comment 6 Jason W. Bacon freebsd_committer 2019-12-14 04:37:14 UTC
World or group writable defaults would be a security risk, e.g. malicious users could plant Trojans on removable media.

That's an inherent risk with all writable FAT media, but one to which individual users should have to deliberately expose themselves with due warning.

I think the default on filesystems that don't support permissions should remain read-only, in keeping with FreeBSD's "secure by default" convention, but we need a clean, simple method for systems managers to customize them.

E.g. something that a slightly more sophisticated /etc/autofs/special_media or mount_* could pick up from a config file, like the numerous flags variables set in rc.conf.
Comment 7 Victor Sudakov 2019-12-14 06:05:38 UTC
(In reply to Jason W. Bacon from comment #6)
> World or group writable defaults would be a security risk, 
> e.g. malicious users could plant Trojans on removable media.

I think actually no, they would not, unless you make all files executable by default ("-m 777" or "-m 755"). "-m 666" should be safe.

> I think the default on filesystems that don't support permissions
> should remain read-only, 

I disagree. Mr. Average User expects to be able to write, move and delete files on the SD card, when he inserts it from his camera to his desktop computer.
Comment 8 Victor Sudakov 2019-12-14 06:07:32 UTC
(In reply to Jason W. Bacon from comment #6)
Or autofs can mount removable media with "-o noexec" by default if we are afraid of Trojans.
Comment 9 Jason W. Bacon freebsd_committer 2019-12-14 15:16:01 UTC
(In reply to Victor Sudakov from comment #7)

You can present those arguments to secteam if you want, but I think that discussion would only delay resolution of the issues we're interested in.

Giving sysadmins the tools to easily configure default mount flags as they please will solve this issue without creating liabilities for anyone else, plus we need this anyway for locale settings.
Comment 10 Jason W. Bacon freebsd_committer 2019-12-14 15:25:17 UTC
Created attachment 209942 [details]
mount_msdosfs hack

Here's am ugly proof-of-concept hack for what I think would be a reasonable approach.  It's by no means production-ready or even the best implementation but it gets the point across.

We might consider doing this sort of thing at the generic mount level, though it's probably not that useful for other filesystem types and suggesting that might meet more resistance.  Limiting it to msdosfs seems like the way to go for now.

<<<ROOT@orca.acadix>>> /usr/src/sbin/mount_msdosfs 1184 # cat /etc/mount_msdosfs.conf 
-m 0770 -g operator

<<<ROOT@orca.acadix>>> /usr/src/sbin/mount_msdosfs 1185 # mount_msdosfs /dev/da1 /mnt
argv[0] = mount_msdosfs
argv[1] = -m
argv[2] = 0770
argv[3] = -g
argv[4] = operator
argv[5] = /dev/da1
argv[6] = /mnt
argv[7] = (null)

<<<ROOT@orca.acadix>>> /usr/src/sbin/mount_msdosfs 1186 # ls -al /mnt
total 36
drwxrwx---   1 root  operator  32768 Dec 31  1979 ./
drwxr-xr-x  21 root  wheel      1024 Dec 12 20:28 ../
Comment 11 Jason W. Bacon freebsd_committer 2019-12-14 15:25:47 UTC
Created attachment 209943 [details]
Header to go with patch
Comment 12 Edward Tomasz Napierala freebsd_committer 2019-12-14 16:05:28 UTC
I don't think this should be specific to msdosfs.  Whatever the mechanism is, we should provide one knob, not separate ones for every filesystem that doesn't support permissions.
Comment 13 Edward Tomasz Napierala freebsd_committer 2019-12-14 16:11:35 UTC
As for defaults: one way would be to do what eg DRI does with the 'video' group: have a group that authorizes access to removable media, and set default permissions to limit access to members of that group.
Comment 14 Jason W. Bacon freebsd_committer 2019-12-14 19:47:37 UTC
(In reply to Edward Tomasz Napierala from comment #13)

Agreed.  I'd be inclined to use the operator group for this sort of access.
Comment 15 Jason W. Bacon freebsd_committer 2019-12-22 15:16:05 UTC
Created attachment 210141 [details]
Generalized default options hack

Here's a more generalized patch that can be easily added to any mount command (or any other command for that matter). It requires a trivial change to each individual mount command.  This means we could test it in production on mount_msdosfs without any risk to other mount commands, then easily add it to others later if desired.

Each configuration file starts with an fstype, as follows:

<<<ROOT@orca.acadix>>> /usr/src/sbin/mount_msdosfs 1063 # cat /etc/mount_defaults.conf 
msdosfs -m 0770 -g operator

This is still just a proof-of-concept prototype.

If you guys like the idea, I'll clean it up and get it ready for commit.

FYI, it seems to me that mount_msdosfs is the only command with read-only permissions.  NTFS and exFAT are supported by fusefs ports and get mounted 0777 by default.
Comment 16 Jason W. Bacon freebsd_committer 2020-01-02 16:12:58 UTC
As I erroneously posted under PR 241475 yesterday:

As for the permissions issues, perhaps the mount directory should default to the ownership of /dev/console, which is set to the user currently running a session.  I think this would be more useful than root:wheel.

This still leaves some issues for multiuser installations, but I think allowing the local sysadmin to control mount options as described above would take care of most of them.

Here's a demonstration of how to set ownership of FAT media to the console user:

<<<ROOT@orca.acadix>>> /home/bacon 1068 # grep -A 2 msdos /etc/autofs/special_media
	"msdosfs")
		console_owner=$(stat -f "%u" /dev/console)
		echo "-fstype=${_fstype},nosuid,sync,-u=$console_owner	:/dev/${_p}"
<<<ROOT@orca.acadix>>> /home/bacon 1069 # ls -al /media/SONY8/
total 33
drwxrwx---  1 bacon  operator  32768 Dec 31  1979 ./
drwxr-xr-x  3 root   wheel       512 Dec 24 07:56 ../

I would only suggest applying this approach as a default for autofs or other temporary mount tools.  Users mounting via fstab or the command line may want different ownership and permissions and autofs users should have the ability to override it (e.g. via autofs_msdosfs_flags)
Comment 17 Victor Sudakov 2020-01-03 13:43:28 UTC
(In reply to Jason W. Bacon from comment #16)
> as for the permissions issues, perhaps the mount directory should default
> to the ownership of /dev/console,

I don't think this will make much sense. A modern Unix system is either a graphical desktop (where nobody cares about /dev/console) or a (virtual) server where the only useful console is serial (if used at all other than at installation time).
Comment 18 Jason W. Bacon freebsd_committer 2020-01-03 14:23:17 UTC
(In reply to Victor Sudakov from comment #17)
>> as for the permissions issues, perhaps the mount directory should default
>> to the ownership of /dev/console,

> I don't think this will make much sense. A modern Unix system is either a 
> graphical desktop (where nobody cares about /dev/console) or a (virtual) server > where the only useful console is serial (if used at all other than at
> installation time).

The point of /dev/console is simply to determine who is currently logged in on the local display.

On graphical desktop systems, /dev/console ownership is generally set to the current user by the display manager.  If that's not true for a given display manager, there are other ways to determine who is currently running a session.

Setting ownership on FAT media to the current user is the most secure way to provide write access to the person who is physically present.

I've managed many workstations that are used both as graphical desktop systems and accessed remotely via ssh, so this can be important.
Comment 19 Victor Sudakov 2020-01-03 16:31:40 UTC
(In reply to Jason W. Bacon from comment #18)
Well, I don't know, I'm sitting now in an xfce session (running from startx), and 

# ls -al /dev/console
crw-------  1 root  wheel  0x4  3 янв.  19:51 /dev/console
Comment 20 Victor Sudakov 2020-01-04 05:45:45 UTC
In Windows, when you insert a removable drive with a FAT/exFAT filesystem (which is most likely to be found on an SD card from a camera or smartphone), any Windows user can write to it. I think this behavior is expected by users, and quite in line with the absence of file permissions on FAT. So I think we should emulate this behavior in FreeBSD due to the POLA.
Comment 21 Jason W. Bacon freebsd_committer 2020-01-04 15:15:11 UTC
If you're not running a display/login manager, then no, there won't be anything under /dev owned by you.  As an alternative, we could grep "ps auxw" for your window manager, or just accept that unusual cases like this won't benefit from this feature.  They certainly won't be harmed by it either, though, provided that the local sysadmin has control over mount options.

I did a little more digging and found that sddm and gdm set ownership of ttyv8 rather than console.  Regardless of the login manager, it's not hard to figure out who's running the local session.

I think we should aim to do much better than the security model of Windows.  There's a big difference between what typical users expect and what's secure.  FreeBSD is advertised as secure-by-default, which is why many people use it instead of Windows.

Any world-writable directory is a tool for malicious users, e.g. a hacker who compromised a user's password.  They could put malicious code on it, which represents a danger even if it cannot be run directly from the external media due to a noexec mount.  It would become a danger when copied to another directory or when the media are mounted on another system that does not use noexec.

In summary, what I'm suggesting is:

1. By default, set ownership of external permission-less media to the current local display owner where it's convenient

2. Give the local sysadmin full control over mount options in any case so they can override the defaults and set other features such as locale

This will ensure that external media can be made writable to whomever they should be.
Comment 22 Jason W. Bacon freebsd_committer 2020-01-04 19:07:32 UTC
I should add that I would rather see a solution that's acceptable to everyone ASAP than to have the ideal solution hung up in committee indefinitely.

While limiting access to the local user by default would be ideal, I think giving the sysadmin control over mount options is the most important part of any solution.  Then everyone can have what they want and there won't be a need to waste time on future debates.

So an implementation of #2 above that allows me to configure *my* system as described in #1 would get my thumbs up.

For the sake of FreeBSD's reputation as a secure OS, I'll always argue against any defaults that create world-writable directories (besides tmp), but I'd rather continue that discussion after this issue is mitigated.

I'll review what we have on the table and follow up with an enhanced patch if necessary.
Comment 23 Jason W. Bacon freebsd_committer 2020-01-05 17:26:12 UTC
Created attachment 210468 [details]
Patch to allow custom mount flags via special_media

This new patch shows how we could allow the local sysadmin to customize mount flags for any fstype.

It only applies to autofs, but I see no reason not to support custom flags both here and within the mount commands.  Maybe we could start with this approach as a proof-of-concept and see if the idea trickles down to mount_* if people want to duplicate it in other mounting methods.
Comment 24 Jason W. Bacon freebsd_committer 2020-01-05 17:28:50 UTC
Created attachment 210469 [details]
Example msdosfs customization script

Example script to work with the special_media patch, with generic defaults that should work on any system and documentation for setting mount ownership as I suggested earlier.
Comment 25 Jason W. Bacon freebsd_committer 2020-01-05 17:50:30 UTC
Created attachment 210470 [details]
Replace printfs from testing with logger