Other file permissions at boot level

[vince66]

Hello guys !

The questions I posed in these mounths was fundamentally addressed to understand the permission setting, how to set owners and groups to manage a device drive and how to mount them in Unix/Unix-like O.S.. Everything with particular regard to a strict security policy: the aim of my questions were to investigate if there was leaks that (in some way) give to an external event the possibility to corrupt the metadata of the files stored on a storage device (usb flash thumb sticks, sata/ide hard disks).

The topics have been analized at user level.

Please, let me try to see the problem at kernel level.

As you taught me, there are several configuration files of the FreeBSD that are take into account during the boot process, to set the numerous and several resources of a workstation.

In one of my latest posts, for example, we discussed about the /etc/devfs.rules file. It is a system file, read at boot time to set some hardware actions.

QUESTION.
Which way does the boot process execute these files ? That is: if I set one of these files in read-only, is the file processed anyway during the boot process ? or not ?
Again, in other words, to avoid confusion: if I've well understood, during the boot process the configuration files are executed by the loader of the O.S. Has the loader or not preferential permissions over the configuration files ?

The same question is extended to the demons, because they run in real time during the normal O.S activity.
Can one of them take the control of an attached drive and corrupt its metadata ?

Thanks in advance.

See you.

 

[ShelLuser]

Which way does the boot process execute these files ? That is: if I set one of these files in read-only, is the file processed anyway during the boot process ? or not ?

Like everything else: the RC structure, see /etc/rc.d as well as rc.d(8).

Basically the first process to start on any Unix system is init. The kernel loads, does it's stuff (like detecting hardware and such) and eventually runs init(8). It does several things and eventually also executes /etc/rc which basically sets the whole thing in motion.

So devfs is simply one part of the whole startup process.

Again, in other words, to avoid confusion: if I've well understood, during the boot process the configuration files are executed by the loader of the O.S. Has the loader or not preferential permissions over the configuration files ?

Actually the loader (kernel is more appropriate I think) transferred control at this time to the RC structure. And that basically gets run as root.

The same question is extended to the demons, because they run in real time during the normal O.S activity. Can one of them take the control of an attached drive and corrupt its metadata ?

Depends on the daemon. Theoretically: sure. During the boot phase everything is run as root so it has full access. Of course several daemons boot while discarding those privileges and running the daemon itself as a regular user account. After that nothing can happen anymore.

 

[vince66]

"Depends on the daemon. Theoretically: sure."

This answer is what I have been looking for months and confirms what I supposed, even if it requires a practical confirmation.
However, let's go step by step, as it suggests many questions.
Please, let me do the first.

Inserting a device into a usb port, we know that the device is only recognized by the kernel but its filesystem is not mounted.

QUESTION.

Running the command:

jerry@maia:/% ls -l /dev/da4

we can see:

crw-r----- 1 root operator ..... /dev/da4
crw-r----- 1 root operator ..... /dev/da4s1

If such a demon (whose identity is at this time unknown for my knowdlege) exists with root privileges, where would it go to write ?

Maybe only in the eeprom of the usb stick chip, admitted that such an operation is allowed by the chip, or could even write in the space of the user memory ?

My question bear because plugging in an hard disk into the sata hot-port, I've noticed that the inserting operation was detected by the chip and a counter inside its memory has been incremented by one every time the hatd disk was inserted. So a write operation has been happen !!!!!! The drive in question is a solid hard disk SSD 1TB Samsung 850 EVO Sata III.
This test, however, has been done on a Linux O.S that is a very disaster in terms of security policy, due to the demons of the GUI !

See you guys !!

Bye.

 

[ShelLuser]

Inserting a device into a usb port, we know that the device is only recognized by the kernel but its filesystem is not mounted.

True, however... small side step: there is something such as autofs(5) which could perform the mounting task for you.

jerry@maia:/% ls -l /dev/da4

crw-r----- 1 root operator ..... /dev/da4
crw-r----- 1 root operator ..... /dev/da4s1

If such a demon (whose identity is at this time unknown for my knowdlege) exists with root privileges, where would it go to write ?

I don't quite understand the question. That is: I can't quite understand what triggers it.

You're basically asking "where would a daemon write its data" to which the answer is once again: depends on the daemon (and how you configured it). Although some might utilize /tmp and/or /var/tmp for temporary data, those two are somewhat mandatory locations.

Also: # ps ux | less would list all current processes run by UID 0.

My question bear because plugging in an hard disk into the sata hot-port, I've noticed that the inserting operation was detected by the chip and a counter inside its memory has been incremented by one every time the hatd disk was inserted. So a write operation has been happen !!!!!!

That sounds more like something done by your BIOS. Some can keep track on a wide variety of things. My Dell PowerEdge for example will even keep track of the times when I open the case.

So I'd look into that direction.

 

[vince66]

"That sounds more like something done by your BIOS".

It is easy to verify. I can extract the bios chip and then hot-plug a drive. In this way the bios will not be able to do anything.

Let me try !