# owner, group, other permission: who can change them ?



## vince66 (Dec 15, 2017)

Hi guys,

I'm again here for a question.

SCENARIO.
The PC has been start-up and is running.
A usb stick / sata hdd is hot plugged.

They are correctly recognized by kernel and their permissions are rw-r--r---.
As you well know the permissions of a file are the first line of defense in the security of a Unix devices.

QUESTION
Are there cases for which implicitly (that is without an explicit command runs by the user) this permissions can be violated ?
That is, can an external event do a writing operation into the usb stick/sata hdd, modifying the metadata of files stored in the filesystem (for example the timestamps informations of the files) ?

If so, can you me do a real example ?

Please, avoid to think strange viruses action. No viruses I intend for external event.
Please, consider, for example, as strange events those for which the processor passes from the protected to real mode (is it possible ? when ? I don't know). 

Thanks in advance.

Vincenzo.


----------



## SirDice (Dec 15, 2017)

vince66 said:


> Are there cases for which implicitly (that is without an explicit command runs by the user) this permissions can be violated ?


The root account can do anything. So everything that runs on the root account can potentially circumvent the permissions.



> Please, consider, for example, as strange events those for which the processor passes from the protected to real mode (is it possible ? when ? I don't know).


This doesn't happen anymore.

What does happen are protection rings. Specifically code running in Ring0 (kernel code) can do pretty much everything unhindered.


----------



## vince66 (Dec 15, 2017)

SirDice said:


> The root account can do anything. So everything that runs on the root account can potentially circumvent the permissions.
> 
> OK ... if so, this means that I need to (create and) login as a user (not root). Is this the 100% secure way to avoid the user permissions violation  ?
> Please, can you confirm this assumption?
> ...


This reply is not clear for me. I apologize for this. So, please, can you tell me more, also with an example ? 

1 - Does happen this also if I login as user not root ?
2-  In which a way, plugging a usb stick in a PC, the kernel code running in Ring0 can do writing operations in the filesystem of the usb stick ? An example is appreciated.

Also bibliography to read is appreciated.
Thanks in advance.

Vincenzo.


----------



## ralphbsz (Dec 15, 2017)

You need to think about this question at different levels.

You say (abbreviated for clarity) "A USB stick is hot-plugged, recognized, and its permission is rw-r--r--".  When you say "recognized", what do you mean by this?

To begin with, a USB stick (or hot-plug SATA or similar hardware) is a device, specifically a block storage device.  One can configure a Unix system (like FreeBSD, or like a Mac, or Linux, or ...) to do very little when a new block device shows up, namely only to detect the new hardware, and create device nodes (for example /dev/da0 and perhaps /dev/da0s1) for it.  If one does that, then the kernel will do no writing to the new device, and only the amount of reading necessary to determine what the partitions or slices on the new device are: the kernel has to read /dev/da0 to get the MBR or GPT, and be able to create /dev/da0s1 or /dev/da0p1 from that read.

In practice, today's desktop operating systems are *not* configured that way.  Instead, they typically run some form of automounter.  That is a service (a process running somewhere, not inside the kernel, but as root and started at boot time), which monitors when new devices are created, and attempts to mount them as a file system.  This is what causes a USB stick to show up in file system space as /media/... when you insert it (in addition to a device node like /dev/da0s0 being created).  The process of mounting will typically write to the raw device, at least a small flag that indicates that this file system is now mounted and dirty (so if the kernel crashes before unmounting it, the next attempt to mount can detect that there may be a need to run fsck).  But: This write does not change files in the file system on the device, it only changes the raw device and internal data of the file system (that is a subtle difference).

The automatic mounting of a hot-pluggable device immediately raises the question of ownership of the new device.  This is a difficult and sticky problem.  One viewpoint is that root runs the system, and therefore root should own the device node /dev/da0s1, and should own the mount point at which the new file system is mounted.  In practice, this doesn't work well, since most USB sticks are formatted with a file system (MS-DOS a.k.a. FAT) which does not carry ownership information, so all files in that file system will look like they are owned by root.  One thing I've seen on Linux desktop machines (with a running GUI) is that newly mounted USB sticks automatically get owned by whoever is logged into the GUI (on the physical console), because the auto-mounting system communicates with Gnome or KDE.  While this is very practical, it is also dangerous: Unix systems are inherently multi-user, and there is no guarantee that the user who inserted the USB stick is the same account as the user on the graphical console.  There is a conflict between convenience and correctness here, and any compromise will be imperfect.

At the next level, many operating systems (definitely Windows or Mac) have search assist daemons, which immediately start reading a newly mounted file system, and then write to it, creating new files.  For example, on a Mac directories called ".fseventsd" and ".Spotlight..." will be created when a USB stick is inserted, and filled with files.  Since these search assist daemons run as root, they can do that independent of the ownership of the file system.  Since I don't run FreeBSD with a GUI, and since I have not enabled automounting, I don't know whether this will happen on a FreeBSD machine or not.

So yes, the newly mounted file system may be written to, by root, automatically.  Whether it is depends on how you have configured your system.

I have never heard of a Unix system that modifies existing files upon mounting a file system, in particular not as root bypassing normal user-based access controls.

You also ask:


> can an external event do a writing operation ... modifying the metadata of files stored in the filesystem (for example the timestamps informations of the files


Yes.  Most file systems have a concept of "atime", the time a file has last been accessed.  That atime is part of the file system metadata (stored typically in the inode of the file, which is pointed at by a directory entry in a directory object).  And it is automatically updated whenever a file is read, independently of who reads it.  So yes, if the newly mounted file system is being read (for example by a search assist daemon like the Spotlight thing I mentioned above), the atimes of the files will be updated, which in turn changes the metadata.  Some file systems (in particular FAT) only have limited atime functionality, and file systems can be mounted with atime updates disabled.

In view of this information, I propose that you ask your question again: what do you mean by "recognized", and what do you mean by "writing"?


----------



## Deleted member 30996 (Dec 15, 2017)

ralphbsz said:


> For example, on a Mac directories called ".fseventsd" and ".Spotlight..." will be created when a USB stick is inserted, and filled with files.  Since these search assist daemons run as root, they can do that independent of the ownership of the file system.  Since I don't run FreeBSD with a GUI, and since I have not enabled automounting, I don't know whether this will happen on a FreeBSD machine or not.



I don't use automount but when I mount a Sandisk Cruiser USB stick as root there will sometime, only sometime, be a BUDA folder created on the drive but it is always empty.


----------



## vince66 (Dec 15, 2017)

Ralph,
you have well understood my question an my needs, and I wish to thank you for the very excellent reply.

Please, let me take stock of the situation so I can propose another question.
I'll try to abbreviate for clarity (and for my needs) the topic you developed in details. Please, assit me if I'll do mistakes.


SCENARIO.
- The PC has been started-up and FreeBSD is running.
- The FreeBSD EXCLUSIVELY runs in console mode (categorically NO GUI).
- A usb stick/sata hdd is hot plugged.

In this situation the kernel only detects the new plugged hardware, and create device nodes (for example /dev/da0 and perhaps /dev/da0s1) for it. Furthermore , the kernel will do no writing to the new device, and only the amount of reading necessary to determine what the partitions or slices on the new device are: the kernel has to read /dev/da0 to get the MBR or GPT, and be able to create /dev/da0s1 or /dev/da0p1 from that read.

QUESTION
The permissions of the usb stick/sata hdd are:
rw-r—r--
and, as you well know, the permissions of a file are the first line of defense in the security of a Unix devices.

In which a way I need to MANUALLY mount the usb stick/sata hdd in the following cases:

1 - fat 16 filesystem (for this type, the 'atime' option has been well commented by you)
2 - fat 32 filesystem
3 - ntfs filesystem

to avoid any modifications of the metadata of files stored in the filesystem (in particular the timestamps informations of the files) ?

Thanks in advance.

Vincenzo.


----------



## ralphbsz (Dec 16, 2017)

For FAT file system, here is my /etc/fstab line (applies to both FAT and FAT32):

```
/dev/da0s1 /media msdosfs noauto,rw,noexec,nosuid,shortnames,noatime 0 0
```
The "shortnames" option is debatable; I don't 100% remember why I use it, I think it has to do with getting lowercase for short file names, which to me happens to be more important than having support for long file names.  That's because most of the USB sticks I mount come from cameras and video recorders, so they tend to have no long file names, but I hate file names that are all upper case.

Actually, most of the time I would be able to mount USB sticks as read-only (with the "ro" option instead of "rw").  That would be very effective in preventing writing to the metadata of the USB stick.  Most of the time, I put a USB stick from a camera into my server, and only copy files *from* the stick, so writing to it is not required.  Once every few months, I bulk delete many files though (at which point it doesn't matter whether their metadata is modified).

For NTFS: it has been years since I last had to mount a NTFS file system, and I don't remember the options.  I think "noatime" and perhaps "ro" would be the right answer.

General remark: The whole concept of Unix' atime is, in my opinion, obsolete.  It was intended for poor man's HSM: detect which files are accessed, and allow deleting files that are not accessed or rarely accessed (or moving those files to different storage media).  Today, HSM is not used very much on most systems, since disk capacities have grown faster than space usage.  And where serious HSM is needed (there is still a market and use for it), it tends to use much more fine-grain information than just the one atime stamp.  The right way to integrate HSM is to use audit logs of file system accesses, and/or integrate it into the file system.  Once you do that, atime becomes useless, and just a big hassle for file system implementors and users.  Fundamentally, everyone mounts everything without atime support anyway, so it has stopped mattering.  Unfortunately, the usage sociology and the standardization process (POSIX and friends) make it very hard to ever remove a feature from shipping systems, since everyone is afraid of upsetting even one big customer.  So we have to live with atime, and turn it off.


----------



## vince66 (Dec 16, 2017)

Thanks very much Ralph !! You've perfectly solved my questions. 

Regards.

Vincenzo.


----------

