Solved daemons: how to penetrate the devices

vince66

vince66

Hello guys,

I will try to formulate an old question with other words, for the benefit of intuition and relying on your knowledge that is more solid than mine.

I already discuss with ShelLuser a first approach to the question.

ps ux - list all the program with superuser privileges.

QUESTION.

Have you experienced (at least once in your life of FreeBSD administrators and programmers) of programs or daemons, with superuser benefit, that "have broken" the mount command (used in read-only mode) and penetrated the filesystem of an attached device ?

At least one !

At least one name of these demons is enough for me, and on what conditions you experienced this behaviour.

In particular this questions refers to GUI O.Ses. .... Honestly, I think that FreeBSD, used in CLI mode, is quite untouched to these phenomena.

See you !
 
vince66 said:
Have you experienced (at least once in your life of FreeBSD administrators and programmers) of programs or daemons, with superuser benefit, that "have broken" the mount command (used in read-only mode) and penetrated the filesystem of an attached device ?
Click to expand...
I don't know what yo mean by "have broken" and "penetrated". Please explain with more detail.
 
I still fail to see what you're getting at with all this but...

Mounting a filesystem readonly is by no means any guarantee that no programs or processes can't access the device itself. For example: if there are filesystem errors which prevent the system from booting you're often dropped into single user mode, this is a session in which the root filesystem gets mounted readonly. This allows you to run fsck on the filesystem without any risk for write actions which could theoretically interfere.

Just to give a drastic (destructive) example: if you mount /dev/da0 readonly on /mnt then nothing is stopping someone who has direct access to the device from issuing # dd /dev/random /dev/da0 after which the filesystem is pretty much toast.
 
sko said:
No, thats incorrect. Please have a look at the ps(1) manpage - what you are searching for is the "-a" switch, which still might have restrictions for non-root users.
Click to expand...
Just to clarify: it is correct when the command is run as root, which was the original context.
 
I generally use ps -aux. This shows all running processes and the account they run on. If you want to list processes belonging to a specific user; ps -U root for example.
 
Your interesting answer invite to clarify the problem better by breaking it down into small steps.

The goal:
Preserve in any way changes of the metadata.

Background:
As you well know, a storage drive is equipped by a small CPU with its memory and the user memory space, devoted to the Boot Record, the partition table, formatting mode (first 512 bytes) and the user data.

Fixed point of the topic (to always assume):
When you plug a USB disk device (or hotplug a SATA disk device), typically what happens is that the OS will read from the disk to figure out partition tables and disk slices. This part is read-only.
In this phase the device is recognized by the O.S. that create the device node (/dev/dax or /dev/adax) and partitions/slides (/dev/daxs1 or /dev/adaxp1).
The creation of / dev / dax and / dev / daxs1 is not separable.

Procedural awareness:
All the operations are executed logging as generic user (not as superuser).

First case: the filesystem is not mounted; it is intact (not corrupted).
Before the operating system takes control of the device by the above operations, the BIOS accesses the disk to verify:
- the device identity,
- its integrity,
- and whether or not it is a boot disk.
- etc.......
Then it passes the control to the FreBSD kernel.

QUESTION 1: Might the BIOS access produce (even only by chance) a write operation in the user memory space, corrupting the metadata of the stored files?

QUESTION 2: Is there the possibility to switch off the BIOS via software, once the O.S. is running ? .... desperate times call for desperate measures !!!!

Second case: the filesystem has been mounted.
ShelLuser said:
ShelLuser said:
Just to give a drastic (destructive) example: if you mount /dev/da0 readonly on /mnt then nothing is stopping someone who has direct access to the device from issuing # dd /dev/random /dev/da0 after which the filesystem is pretty much toast.
Click to expand...

Let us consider this sentence.

QUESTION 3: which is the file/daemon name of this "someone who has direct access to the device" ?

Thanks guys !! You are great !!

See you.
 
This is just my opinion but I cannot help get the feeling that you're heavily over-analyzing this stuff and trying to fix problems which aren't even there. Now, that process by itself isn't much of an issue because that's usually how oddities and optional mishaps get discovered. However, in those cases people already knew about the basic behavior of whatever it was they were working on or they were busy finding out for themselves.

Simply put: You can't hope to discover and/or solve any problems if you lack basic understanding of how things actually work. Because in that scenario it's also quite likely that you may experience something to be a problem while in fact it's actually a feature. That well known saying wasn't just meant as a joke ;)

If you want to preserve data then make a backup. It's really that simple. Also: storage devices don't necessarily have memory, CPU or a BIOS.

Answer1: This forum deals with FreeBSD issues, lets not get carried away. The reason I say this is because your questions become way too broad for me. "BIOS"? There are dozens of different BIOS types out there, even more so now that several machines work with UEFI. A BIOS corrupting something? Possible, but that's purely theoretical and speculative, let's stick with the facts instead.

Answer2: Same as #1. Also: try reading up on what a BIOS actually is and does. To me this question falls within the same category as "Can you turn off a PC's CPU?". It makes no sense, it serves no purpose and the answer is "it depends". The easy answer obviously being: turn off the PC and be done with it :p Even so, this also has little to do with FreeBSD.

Answer3: Everything running with a UID of root and/or which has OS level access to the device nodes. One sure way to prevent this from happening is by using # sysctl kern.securelevel=2, this will effectively prevent any direct write access to storage device nodes (excluding mount). For more information see security(7).
 
Hello ShelL,
ShelLuser said:
This forum deals with FreeBSD issues, lets not get carried away. The reason I say this is because your questions become way too broad for me.
Click to expand...

I partially am agree with you about the fact that this forum deals with FreeBSD issues.

When the topics are multidisciplinary and some issues are strictly related with the freebsd's architecture, implementation and design, I think that the question is welcome and must be posted here.
And .... also because there are not other so power OSes like FreeBSD (always in my opinion).
Obviously the reply is left to those member that have the corresponding knowdlege.

Again: honestly, there's not other forums so devoted like the FreeBSD Forum, where new members (like me) are continuosly assisted by all of the members with high experience, from basics knowdlege levels to those higher.

So, thanks very much.

About your answer: I'm going to investigate your sentence about security, but I think, this time, you have centered and solved the problem I posted.

See you !!!

Heve you a nice day.
 
You must log in or register to reply here.
Back
Top