sudo on risky machine - passwordless or not?

cracauer@

Developer
Say you have a dedicated machine to run risky applications, e.g. Chinese LLMs.

Would you make sudo for that machine passwordless or passwordy?
  • Passwordy obviously has the advantage of delaying an attacker when they want to do system changes.
  • But the disadvantage comes in when they install a userland password sniffer. Since you force yourself to enter the password regularly you play into their hands.

What do you do?
 
If it's a dedicated machine, paswordless might do. First, you don't have the risk of using a password that is similar to other passwords of yours and gets sniffed. Second, why bother; make sure the machine is well isolated and have fun.
 
That's a good question. Does jailing help isolate anything?

The whole bare metal is an isolated install. It also has snapshots that cannot be reached from said machine.

A jail wouldn't help with the sudo question, unless you opt to never sudo in the jail at all. Which might or might not be doable but certainly a major pain.
 
  • Like
Reactions: mer
So the machine is basically air-gapped from everything important, you need to physically be in front of it (not ssh in)?
Sounds like if the machine was compromised it shouldn't be able to infect anything else?
 
I'd say it doesn't matter, a motivated adversary with a shell access will find a way to gain root anyway. The more important question is to know if this machine has internet access (it shouldn't).
 
If the purpose is really to test Chinese LLMs or Chinese software in general, I recommend that you create a subdirectory Pictures in your home directory (if it's not already there) and you fill it with photographs of Mao Zedong. This way, the malware will think that you are faithful to the CCP and probably will leave you alone. Here is a picture of Mao Zedong:

MaoZedong.jpg
 
Given that you've already identified it as an untrustworthy machine, I don't really think it matters. Just properly isolate/firewall it, so that it cannot be used as a spearhead for further incursions.
 
If the purpose is really to test Chinese LLMs or Chinese software in general, I recommend that you create a subdirectory Pictures in your home directory (if it's not already there) and you fill it with photographs of Mao Zedong. This way, the malware will think that you are faithful to the CCP and probably will leave you alone. Here is a picture of Mao Zedong:

View attachment 25608
Could even be a way to test the said "intelligence" of the LLM. 🤣
 
If the purpose is really to test Chinese LLMs or Chinese software in general, I recommend that you create a subdirectory Pictures in your home directory (if it's not already there) and you fill it with photographs of Mao Zedong. This way, the malware will think that you are faithful to the CCP and probably will leave you alone. Here is a picture of Mao Zedong:

View attachment 25608
Actually, you need pictures of a bear who likes honey nowadays. :-)
1773260119161.png
 
Given that you've already identified it as an untrustworthy machine, I don't really think it matters. Just properly isolate/firewall it, so that it cannot be used as a spearhead for further incursions.
I agree, won't make much difference. Just keep it off your lan. I guess if you're really paranoid you could disconnect the microphone, if it has one, and tape over the camera. And of course take any wireless adapter out. Speaking purely personally, I wouldn't install it on my hardware in the first place. How do you know it doesn't leave something behind after you think you've removed it and want to use the hardware for something else. I guess you could sacrifice a cheap ssd.

China clearly has some serious hacking capability. Not to be under-estimated.

Of course... it's probably safe. Probably... :)
 
Speaking purely personally, I wouldn't install it on my hardware in the first place. How do you know it doesn't leave something behind after you think you've removed it and want to use the hardware for something else.
I agree, although the problem is not so much about "installing a Chinese LLM" than giving it a way to eval code.

A LLM, by itself, is just a save file, really. We don't know what's in it (it's just as opaque as a proprietary binary), but it doesn't execute code. The inference engine (llama.cpp, pytorch, etc) and the tools build upon their API are the real problems: what capabilities does they provide to the model? If it just displays text on a screen, there's little harm the model could do. But if the inference engine provides features (like tool calling) for the model to be used as an "agent", to give the model direct access to a shell, a python interpreter or any way to eval, now that's a problem. Same when an IDE decides to eval the output of the model. Because you have no way to audit the weights of the model to check if it was not trained to do something malicious under given circumstances. And by the way, that's a problem for all models, Chinese or otherwise. Running them with eval capabilities should be considered running proprietary software.

I say that having myself homelabs running tons of models. :) Perfectly fine when their output is just strings displayed on screen, or used in other programs, but treated with the same level of care than random user input.
 
The case for capability based systems is becoming stronger and stronger, where each third party library is in its own sandbox and can only access things for which it has capabilities -- so for example it can't even make syscalls except beyond what would be needed to perform its task. Of course, they can still use hardware insecurities (such as spectre) if present and not mitigated in the OS.
 
So the machine is basically air-gapped from everything important, you need to physically be in front of it (not ssh in)?
Sounds like if the machine was compromised it shouldn't be able to infect anything else?

It is not airgapped. What I mean it doesn't have anything important on it and is dedicated to the messy tasks. It is in fact PXE booted, with a local disk only for the models. Snapshots and diiffing of snapshots happen on the server. The machine has no access to the snapshots.

It's a desktop, so no mics or cameras around.
 
I agree, although the problem is not so much about "installing a Chinese LLM" than giving it a way to eval code.

A LLM, by itself, is just a save file, really. We don't know what's in it (it's just as opaque as a proprietary binary), but it doesn't execute code. The inference engine (llama.cpp, pytorch, etc) and the tools build upon their API are the real problems: what capabilities does they provide to the model? If it just displays text on a screen, there's little harm the model could do. But if the inference engine provides features (like tool calling) for the model to be used as an "agent", to give the model direct access to a shell, a python interpreter or any way to eval, now that's a problem. Same when an IDE decides to eval the output of the model. Because you have no way to audit the weights of the model to check if it was not trained to do something malicious under given circumstances. And by the way, that's a problem for all models, Chinese or otherwise. Running them with eval capabilities should be considered running proprietary software.

I say that having myself homelabs running tons of models. :) Perfectly fine when their output is just strings displayed on screen, or used in other programs, but treated with the same level of care than random user input.

That gets fuzzy very quickly. I use the emacs extension gptel as a frontend and it can give access to file buffers (for coding related purposes). What do I know whether shell and Lisp buffers are also usable from the LLM?

I also want to experiment with agents. There it gets really wacky.
 
That gets fuzzy very quickly. I use the emacs extension gptel as a frontend and it can give access to file buffers (for coding related purposes). What do I know whether shell and Lisp buffers are also usable from the LLM?

I also want to experiment with agents. There it gets really wacky.
I would totally consider both of that giving the model eval access, yes.

Then again, if you're running it for doing experimentation and seeing what the tech looks like, no need to go full DEFCON on it either. :) It's as bad as running proprietary code, no less no more. I would not worry if it's not an habit to let it run for months doing whatever it wants. I would hope for more intensive users to hit any problems and to go public about it before it has a chance to hit me (not failsafe, but good enough).
 
I would totally consider both of that giving the model eval access, yes.

Then again, if you're running it for doing experimentation and seeing what the tech looks like, no need to go full DEFCON on it either. :) It's as bad as running proprietary code, no less no more. I would not worry if it's not an habit to let it run for months doing whatever it wants. I would hope for more intensive users to hit any problems and to go public about it before it has a chance to hit me (not failsafe, but good enough).

Good points. But I am also concerned about a LLM wiping out filesystem contents by accident, like Google's Antigravity did.

I think against accidents it is the better solution to require a password for sudo as an LLM can casually use sudo with good intentions and be wrong. But it wouldn't install a password sniffer by accident.
 
Agreed. My angle in this discussion was security against a malicious agent, but dealing with stupid choices made on good faith is also an issue. Deciding what's the worst you allow to happen is good design. Plus, with sudo, you can give no password access to specific safe commands if you want to.
 
Yesterday I have seen some demos from people further along in the AI journey than me. From what I have seen I wouldn't rule out that a LLM could turn destructive without the authors doing anything along those lines. Some Discord conversations between the agents were pretty insane.
 
Yesterday I have seen some demos from people further along in the AI journey than me. From what I have seen I wouldn't rule out that a LLM could turn destructive without the authors doing anything along those lines. Some Discord conversations between the agents were pretty insane.
Almost sounds like giving statistical-classifiers-prone-to-hallucinating shell access could be a bad idea. ^^
 
I wouldn't rule out that a LLM could turn destructive without the authors doing anything along those lines.
From The dead Internet is not a theory anymore:

I recently invited a job applicant to a first-round interview. Their CV looked promising and my AI slop detection didn’t go off. But then I got this reply:

job applicant


This made me realize that the dead Internet arrived faster than expected. A few other purely qualitative examples confirmed the feeling.
 
Back
Top