What's the purpose of mdo?

[UJuwMLAx]

I mean in a broader sense, not the technical "[to allow] unprivileged users to change process credentials" from mac_do(4). You see, before switching from MS Windows to FreeBSD I became a bit familiar with sudo on some linux machines at my job. My understanding is that sudo is for escalating the user's privileges in a controlled way for certain specified tasks. This usually requires the interactive authentication of the original user (password input) but I have seen sudo set up also to work without any password input for certain set of commands. So far so good.

Now, on my FreeBSD machines I try to avoid GPL-licensed software, so I was looking for a FreeBSD-native alternative. Vermaden describes several of them, and I went with mdo(1). I have set it up on one of my machines and it does the job. All good. I am just a bit puzzled about how much the security of that machine is compromised by it. (Maybe security is not the correct term here). I mean the situation where somebody (e.g. my spouse, kids, a visitor) who does not know my password gets the chance of interacting with that machine under my user's account. Why is there not any kind of protection when using mdo? Like requiring my login password or something?

I know that there is this way to "hijack" a FreeBSD machine when you have physical access to it (reboot into single user mode and reset the root password) and that this is not considered a security issue because by declaring a tty "secure" in /etc/ttys you basically tell the machine that you want this safety hatch open and it shall just trust the site's physical access security measures. But apart from that: Let's assume I am remotely logged in my FreeBSD machine from some place insecure and that somebody who does not know my user's login password gets his hands on this console under my account. The moment he tries to execute anything through mdo, he effectively becomes root, no questions asked. And I'm not sure I want it this way. With sudo this would have probably not happen (after the password caching period has passed).

When I think about it, I must conclude that if you use mdo to grant any user the root's privileges, this user effectively becomes root, too. And if that user account is partly compromised (password and other credentials are still unknown to the attacker, but he has physical access to one of the user's consoles), the door is wide open. Is that the intention behind mdo?

 

[elephant]

I must conclude that if you use mdo to grant any user the root's privileges, this user effectively becomes root, too. And if that user account is partly compromised (password and other credentials are still unknown to the attacker, but he has physical access to one of the user's consoles), the door is wide open. Is that the intention behind mdo?

This is how it works. Your characterisation of the risks is accurate. If you want gated access to root, su - is probably better.

 

[jardows]

If mdo is not secure enough, and you want to avoid GPL software, security/doas from OpenBSD is a great alternative.

 

[turingo]

Purpose of mdo is to not rely on setuid programs (sudo, doas) for privilege escalation. Binaries with setuid bit come with their own surface attack.
But as you mentionned, mdo cons is that it won't prompt for auth (at least for the moment). Maybe in the future, it will have a polkit like mechanism for it.

 

[Zare]

I know that there is this way to "hijack" a FreeBSD machine when you have physical access to it

Yes, physical and digital security are two different things. If you have reason to believe somebody malicious could get hands on access, then the digital security part must be done differently, with encryption and very large levels of prudency in the workflows...

But apart from that: Let's assume I am remotely logged in my FreeBSD machine from some place insecure and that somebody who does not know my user's login password gets his hands on this console under my account. The moment he tries to execute anything through mdo, he effectively becomes root, no questions asked.

Probably because MAC is not designed for desktop usage. Nobody assumes a server admin will SSH into his box from Internet caffe and just leave it running.

When I think about it, I must conclude that if you use mdo to grant any user the root's privileges, this user effectively becomes root, too. And if that user account is partly compromised (password and other credentials are still unknown to the attacker, but he has physical access to one of the user's consoles), the door is wide open. Is that the intention behind mdo?

Yes you're correct again. But you have to take context into account. Mdo does what nopasswd sudo/doas do, and people use them all the time. I don't but people do (I use plain su).

The "root" security isn't that important any more. It may sound stupid, but malware has changed. Botnets are going through browsers. When I connect to streaming site to watch something (with adblock/firefox), no ads, clean UI, but the CPU usage is still abnormal. There is no need to infect someones PC when all you have to do is get them to click a link and their computer now runs a browser script that is able to arbitrarily connect to anything.

It doesn't have access to the user account and that's where modern OS level malware comes from, you don't need a rootkit for a typical "My Documents" encrypt ransomware.

Back then, the computer was much more useful than user data. It was attractive to hack web servers by hacking a weak-security Apache site instance to get a shell for www user account, and then proceed further to get access to the box, because the box is an Internet server. Unless there is specific ecommerce data on it, the user stuff is "garbage" and hacker wants to use the server as hardware and the Internet link.

Personally if my user account gets hacked or intruded, the only thing that makes the matters worse if they manage to get root, is they would be maybe able to conceal their affair for longer. In the end the damage is the same because by definition my user acc has access to my data which is the most important thing on this machine.

 

[fernandel]

I mean in a broader sense, not the technical "[to allow] unprivileged users to change process credentials" from mac_do(4). You see, before switching from MS Windows to FreeBSD I became a bit familiar with sudo on some linux machines at my job. My understanding is that sudo is for escalating the user's privileges in a controlled way for certain specified tasks. This usually requires the interactive authentication of the original user (password input) but I have seen sudo set up also to work without any password input for certain set of commands. So far so good.

Now, on my FreeBSD machines I try to avoid GPL-licensed software, so I was looking for a FreeBSD-native alternative. Vermaden describes several of them, and I went with mdo(1). I have set it up on one of my machines and it does the job. All good. I am just a bit puzzled about how much the security of that machine is compromised by it. (Maybe security is not the correct term here). I mean the situation where somebody (e.g. my spouse, kids, a visitor) who does not know my password gets the chance of interacting with that machine under my user's account. Why is there not any kind of protection when using mdo? Like requiring my login password or something?

I know that there is this way to "hijack" a FreeBSD machine when you have physical access to it (reboot into single user mode and reset the root password) and that this is not considered a security issue because by declaring a tty "secure" in /etc/ttys you basically tell the machine that you want this safety hatch open and it shall just trust the site's physical access security measures. But apart from that: Let's assume I am remotely logged in my FreeBSD machine from some place insecure and that somebody who does not know my user's login password gets his hands on this console under my account. The moment he tries to execute anything through mdo, he effectively becomes root, no questions asked. And I'm not sure I want it this way. With sudo this would have probably not happen (after the password caching period has passed).

When I think about it, I must conclude that if you use mdo to grant any user the root's privileges, this user effectively becomes root, too. And if that user account is partly compromised (password and other credentials are still unknown to the attacker, but he has physical access to one of the user's consoles), the door is wide open. Is that the intention behind mdo?

https://blog.hofstede.it/mdo-on-freebsd-15-base-system-privilege-delegation-with-mac_do/

 

[elephant]

Quoting fernandel 's linked article.

A consequence worth stating plainly: treat every account allowed by mac_do as effectively privileged. If an attacker gets that user’s SSH key or shell, mdo will not provide a second authentication barrier. The trade is intentional, but it has to be reflected in how you manage the source-side accounts (key hygiene, no shared logins, no interactive password fallback on SSH).

 

[jwillia3]

I don't think mdo(1) is made to be a sudo(1) or doas(1) replacement.
I believe it is made for things like services to switch users for subprograms.
This way, the original service does not have to be root in order to assume another user's credentials, and mac_do(4) allows the mdo binary to not be setuid.

SECURITY CONSIDERATIONS
The mdo program is geared to role-based scenarios. Consequently, it
does not ask for any password or request other form of authentication
before trying to establish new credentials, instead relying solely on
the requester's credentials for this purpose.

Specific unprivileged uses may be enabled by using the mac_do(4) secu-
rity policy.