@Motivated Absolutely from a Linux console in a different TTY.
In fact, you shouldn't be using sudo. You should log in as root from a different TTY to perform any activities that require root privileges, and log out when finished.
Otherwise, the user from which you elevate privileges can compromise root.
@forest In many (most?) current distributions, sudo is configured by default so that its token is only valid on the tty it was created for. So any new terminal (virtual console, tab in an emulator, screen window etc.) provides a safe environment for sudo.
I prefer that users run sudo rather than logging in as root: that way their activities are logged, and no one knows the root password, so permissions can be controlled in a finer-grained manner.
@StephenKitt The problem is the fact that the environment can be compromised.
If the environment is compromised, then so is sudo (yes, I know it's setuid so you can't use LD_PRELOAD on it, but there are plenty of other ways).
The issue is the same as with su.
You're right that it improves the ability to log commands, but that can also be done with auditd in a way that is less easy to bypass (no bypass with sudo -i or sudo sh).
So I guess it depends on a tradeoff between basic non-repudiation and security.
My point is just that, if you let me run a program as user foo, then you later use sudo at said user to run something (anything) as root, I will be able to get root.
Most people want it to act like Windows UAC and don't care about non-repudiation.
@forest yes, indeed, but arguably the problematic step there is letting you run a program as user foo in the first place, not letting you run sudo ;-). (Cue dire warnings about web browsing etc.)
@StephenKitt Sure, but then why not just run everything as root?
If you're under the assumption that a compromised unprivileged user is the end of the world, then there is no security reason to separate root and non-root contexts.
@StephenKitt That's why I specified security reason. It's true that non-root can be a safety net to prevent obliterating partitions and the like.
But in terms of security, there's little (but not no) difference between running su or sudo under your regular user with a strong password, and with no password.
After all, I don't want a browser bug to be able to mount my backup partition. :P
@forest that’s still part of the security assessment in my book, but yes, I agree that there’s little difference in practice, and sudo-capable users should be considered to be equivalent to root.
@forest yes, and a good argument for running apt with TLS (and before anyone says anything, that wouldn’t fix everything, but it greatly reduces the risk of MITM).
@StephenKitt I think we're thinking about this from different frames of reference. I'm thinking about it from the perspective of a vulnerability in a program being run by the user, like ffmpeg, whereas it seems like you're thinking about it in terms of a multi-user system where each user may or may not be trusted.
I am thinking in the context of administration done by the sysadmin.
E.g. SSH in to your server and run sudo under the same account you run rtorrent on when you want to perform administrative tasks, or SSH in directly as root using public key auth. The former means an RCE in rtorrent pwns the whole system. The latter just results in people new to security freaking out at you because they learned that root SSH = bad (without knowing that public key auth mitigates that).
That's why I always recommend things like SSHing in as root (or in the case of physical terminal access switching to a new TTY, performing the SAK sequence, and logging in directly as root) on security-sensitive systems.
Sandboxing, syscall filtering, mandatory access controls, kernel config hardening, etc.
It's easy to prevent a local user compromise from becoming a root compromise, but it requires letting go of traditional behavior and compartmentalizing administration.
For most people, the step of enabling the SAK sysrq sequence alone is too much of a hurdle to prevent them from casually running sudo -i or su in xterm.
And most sysadmins learn by administering their own system and then try to use the same techniques to manage multiple systems and security-sensitive systems...
In my previous job, no one ever logged in to security-sensitive systems.
For Windows, I think Process Explorer shows you all the threads under a process.
Is there a similar command line utility for Linux that can show me details about all the threads a particular process is spawning?
I think I should have made myself more clear. I do not want to see the process hi...
@forest I'm curious as to why sudo shouldn't be run. I read through the comments between Stephen Kitt and you. It's my understanding that if a user runs the command sudo, it can be compromised. It isn't clear to me how it could occur.
@StephenKitt - It seems that no one knows if rpm can natively list all orphaned or unneeded packages. Would you know?
@StephenKitt - What do you mean by dire warnings about web browsing?
@forest What do you mean by there is no difference between running su or sudo under a regular account with a strong password and with no password?
I have installed some rpm package on my Fedora 17. Some packages had a lot of dependencies.
I have removed some packages but I forgot remove unused dependencies with yum remove.
How can I do that now?
@StephenKitt To clarify, do you mean that rpm is unable to list orphaned packages? When you say it doesn't manage packages at the right level, what do you mean?
@StephenKitt - There is no description in mine. Actually, there is. It's much further down the page.
@StephenKitt - It reads "rpm is a powerful Package Manager, which can be used to build, install, query, verify, update, and erase individual software packages"
@StephenKitt Are you referring to "A package consists of an archive of files and meta-data used to install and erase the archive files."
Well, I certainly learnt something about when shells are supposed to invoke regular built-in utilities today. Thanks to mosvy and JdeBP. unix.stackexchange.com/questions/496259
It feels nice to be able to plug holes in one's understanding.
For Windows, I think Process Explorer shows you all the threads under a process.
Is there a similar command line utility for Linux that can show me details about all the threads a particular process is spawning?
I think I should have made myself more clear. I do not want to see the process hi...
I have installed some rpm package on my Fedora 17. Some packages had a lot of dependencies.
I have removed some packages but I forgot remove unused dependencies with yum remove.
How can I do that now?
