No matter if you sudo or su, at least we can all agree that this is like a million times better than "Are you sure you want to run this as admin? [Yes] [No]"
That's what I was think of! But hey... don't forget all of the "security updates" MS force you everytime... they do it for you man! So you can have a very safe machine!
Another advantage of using sudo accounts, is accountability in seeing in the logs who did what on the system. If all actions are done by root, no matter who logged in. You have no accountability.
That is one very important reason to use sudo. It is better also in some other reason. 1. Accountability 2. You don't have a shell logged in a root and do some things when you think you are a ordinary user. 3. Access to root is just used when needed 4. A well known account, root, make it easier to hack the computer from remote. Debian use more fine grained security, that is why they don't use wheel group. Instead divided into many different groups.
That's a false argument. You can always see who did log in as root to which terminal (which user in case of su or from which IP in case of SSH.) and what commands have been ran from that terminal.
The 'enhanced' security that `sudo` might provide over `su` is a fallacy in my opinion. You can still login as root with `sudo -i` or `sudo -s` depending on what you want to do. You can neutralize your system with a single command or a bunch of them. It's brute power regardless of how it was attained. It's mainly a matter of what and how often you perform your system maintenance. Sometimes you might want to do a bunch of tasks and it's more practical to switch user as `root` and perform them. Using `su` is not old school. It's still valid and alive today. With `su` you *need* the `root` user password. With `sudo` you use your user's password and hence you won't compromise the `root` account and you can also limit the commands a `sudoer` can execute. Ultimately it's a matter of taste, workflow and security policies.
Most users watching DistroTube's channel are single-user desktop users so by definition they can do anything because they know the root password regardless if the user account has sudo privileges or not. sudo is more secure even on single-user systems. Once you have a normal user configured with sudo provileges, the root account can be disabled.
@@0x007A to an extent. You could use different passwords for the accounts and still plan workflows that enhance your productivity and/or enjoyment of your system. Regardless good practices can be applied to domestic systems.
And the system owner kan look in logs and see who did it. So the use of sudo is traceble, su is not. And yes, you send the logs to another machine. That is why proper time is so important And as you mention, sharing passwords are bad. With su you must share root password. And you have to have another good password on the root account, unless you uses sudo
@@OctaviusPelagius people use sudo for convenience on their personal computers. I disabled the sudo password requirement because I am the only user, I have to type 'sudo ' (5 characters) anyway before the actual command to be performed so I am not likely to type 'sudo rm -rf /' by accident. The 'sudo' command provides an automatic audit trail although as the only user on the computer with a strong password the audit trail is a moot point. If someone has physical access to my computer, they could boot from USB drive and mount the partitions - I keep sensitive data on a removable drive and it is only plugged in when needed. I used to habve my /home/username mounted from a microSD card but performance and occasional GUI freezes forced me to return to on-disk /home/username. Maybe the microSD card has problems with ext4?
sudo is a security nightmare. There are tons of vulnerabilities connected to sudo and administering sudoers files for many users on many machines is almost impossible. So while it might make sense for home desktop users who don't know what they are doing, it doesn't for bigger companies with large number of servers and users. Also if a user have unlimited sudo access then the attacker only need to know his password to get complete control of the system instead of the root password which is usually much harder to get. The SSH argument is just showing your lack of knowledge. No one should use password authentication on SSH especially on machines connected to internet and you can disable root access on SSH level as well so no need to disable root on the system level. I work as system engineer for large companies for more than 20 years and there are many reasons why we don't use sudo.
Actually there are a number of issues with the binary (root/user) permissions method, and note that Windows really copied that system. Its not for nothing that hackers talk about "flipping the permission bit". There is no real reason to have a "super" access to everything. There are a number of ways to improve this. 1. Separate the permissions out by type and have users individually obtain each type (like access to a particular disk tree, for example). 2. Stop requiring applications be installed globally. Most applications can be installed in the user directory, meaning that installers don't need root access. 3. Give users the ability to form sandboxes easily. You are installing software. Why does the installer need root permissions? It only NEEDS permissions to its install directory and perhaps a few other resources. 4. Remove the "flip permissions" ability. The OS should not give every user in the system the ability to boost their access level. A better model is to have processes be able to restrict access, but never add it. Thus the root spawns user logins, and a user process can execute a subprocess with less permissions that that, but no process can boost their access back up again. It means if you want higher level access, you have to use a higher level account. The improvement is that there is no way to increase your access level programmatic ally via the OS. None.
Regarding logging in as another user (either fully, or just in a terminal session) is that yourself can be a danger. Say, you do take a break and come back some time later and forget that you're logged in as root (I know, in terminals you have a different prompt, but not everybody is used to that). And if you forget that you're logged as root, you might do things that you don't want to do. Commands that you run and that create files or folders, they will be owned by root. And you might find out later that your user doesn't have access to them or that some daemon cannot interact with said files anymore or things of that nature.
The sudoers file is a mighty tool. You could restrict users to specific programms as root etc. But it's best suited for server usage. But if you're using just a single desktop system, use doas.
nah, the whole argument for doas is removing complexity and potential vulnerabilities added by features you dont need, but at that point, why even use doas? just cause its less likely doesnt mean it cant contain vulnerabilities, so why not go the extra step and remove that too?
@@coolbean9880 That's a silly argument because what you're saying is that you can't trust your software because it adds complexity, vulnerabilities and features that you don't need. Okay, it's a "strategy", I guess, but then the only thing you can trust is you, as the user. And if you trust "you" completely, then just use the root account all of the time - and don't even mess with "su", "sudo", "doas" or even normal user accounts, all of which (by your definition and not mine) add complexity, vulnerabilities and features you don't need.
@@terrydaktyllus1320 why would i need any more confidence to use su, then exit when im done compared to just using sudo/doas? the effect is ultimately the same and on your home computer the odds of someone messing with your home computer after youve left with a terminal still logged into root are typically limited to pets and children, both quite easily thwarted with a screenlocker im simply taking the logic to a more extreme extent specifically to point out how the train of thought behind using doas on systems that use it natively are either a. paranoid bullshit or b. trying to flex because you're technically protected against incredibly rare user previlege escalation exploits in a single application on your computer (though a lot of the latter dont even end up actually removing sudo from their system so it often remains accessible using it's absolute path)
Same here, used Slackware from 98 - 2008. Even with sudo my level of discipline and focus still remains over a decade later. It has become second nature to reconfirm my decisions a few times before hitting enter.
If some bad agent gets physical access to your computer, surely you got bigger problems than file permissions That said sudo is a great tool to protect the user from himself. Just the extra confirmation prompt alone already saved me from doing some undesirable actions
A terminal is a basic thing that is almost always open on my computers, often with multiple tabs with SSH sessions and what not. You will also most of the time, find one or two 'sudo -s' tabs. If I need to do more than a single command as root, I always launch a root session. The advantage of sudo is not that su allows someone to sit down at your computer. The worst damage to my system would be to delete my personal files, no root required. If they only break the system, I can simply restore it. Also, I know who is in my house at a given time and I switch off or lock my computers when not using them. The advantage of sudo over su is the fact that you can disable root login. Anyone requiring root will have to go through sudo initially to do so. On a personal system with a single user, I don't think this makes any difference at all. If you have a user password, that password can easily be used twice using sudo. But on a corporate network this will make a huge difference. Each user will have there own separate password, logs can be traced much easier, temperately access can be granted without exposing some shared super secret password etc.
I'm using Doas instead of Sudo, I regret nothing. Also having to set up the config yourself is a level of transparency I can subscribe to. Literally one line and less than fifteen characters across is enough to keep you from borking your single-user setup.
With respect, in Gentoo Linux I just make a simple removal of a "#" at the beginning of a line in /etc/sudoers to allow me, as a member of the "wheel" group, to use sudo. So I am doing it in 14 less characters than you are in "doas".
I remember the su command from my Red Hat Linux days. Absolutely correct, if you logged in as root user, basically anyone with access to the terminal is logged in as the root user.
That's why "Basic Security 101" says "Don't leave your PC unattended with a logged in terminal" and "make sure you configure terminal timeouts". If you don't understand those two basic concepts, you should be nowhere near a root terminal, because you are not an adult.
@@keylowmike85 I don't use Windows these days (I kicked that crap out of my life when Windows 7 support ended) but I do wonder about those people that think Windows 10 is a usable OS - when all I see is a Microsoft advertising platform that steals all of your personal data, takes charge of the PC you bought with your own money and then "leases" it back to you as it sees fit. They talk about the "Software As A Service" model, but Microsoft goes one better and makes it "Your Hardware As A Service". Good riddance to my Microsoft abuser.
@@terrydaktyllus1320 I, unfortunately, can't remove Windows because my work laptop is running Windows 10. But my personal ThinkPad is running Linux. I've always been drawn to Linux because it offered freedom.
@@keylowmike85 My day job is with Linux servers, my work gives me two laptops - one with Linux on it, the other with Windows 10 on it. (The Linux one is a Thinkpad, plus I have a large collection of Thinkpads at home, all running Gentoo Linux.) The Windows laptop sits in a corner gathering dust except for 30 minutes on a Friday when I have to use it for a time reporting application that only seems to work on Windows. I have configured my network to put the Windows laptop in its own VLAN on its own so that it cannot communicate with the rest of my home network and it can only connect to the outside world when it's VPN is active to my work network. I do not allow that disgusting operating system anywhere near my home network - even the wife uses only CrApple devices which are slightly better than Windows 10.
You can also use sudo to allow certain commands to be run as a different user. For a single user system it may not be the most important use, but for a multi-user system it can be handy.
I wanted to note something about the su method. Both here and in another video of yours I remember you saying something along the lines of "su to the root user and then su back to your regular user". That is even worse of a security risk! Su opens a new shell instance with the user you specify, so you end up with nested shells, meaning that after you su back to the regular user, a mailcious attacker could just type "exit" to quit the regular shell and get back to the parent root shell! Example: $ echo $UID 1000 (regular user) $ su root Password: ... # echo $UID 0 (root user) # su user $ echo $UID 1000 (regular user) $ exit # echo $UID 0 (back to root user!) # exit $ echo $UID 1000 (back to regular user) $ exit shell exits Instead of doing su user, simply exit the root shell. $ echo $UID 1000 (regular user) $ su root Password: ... # echo $UID 0 (root user) # exit $ echo $UID 1000 (back to regular user) $ exit shell exits
At a previous job, our Linux setup was a little weird. We had a service account on the machine that 'owned' the webserver or DB server, etc, application, but we had to log in with our own user account. By adding the user accounts to the sudoers file and only allowing certain commands -- sudo su [account] and sudo su - [account] -- we could share the service account without having either the root password nor the service account password.
OpenBSD's doas is much simpler than sudo. I do remember, back in the days, also the toor account used to split root. Last, nowdays alot of systems have predictable users like mysql,backup,postgres,etc.
I run (Gentoo) Linux at home and work on (Red Hat) Linux servers. I have taught myself the "lowest common denominator" tools for system administration, maintenance and hardening - "learn one thing and use it everywhere" is my mantra. Vim, sed, awk, bash, etc. may seem "boring" to some people but they are mainstay applications that are installed everywhere. As far as I am concerned "doas" is just another application for "fashionistas" that doesn't really offer anything more, from a functional perspective, that "sudo" does - if it did, I would have now become the de-facto replacement for sudo. By all means run your "doas", "fish" or "zsh" shells, and your other "apps to make me look cool to my peers" on your own systems, but don't then blame anyone else but yourself if you get to a time where you're working on someone else's systems and are not allowed to install your "fashionista" apps on them.
I don't buy the "physical access" argument. Unless you fully encrypt your hard drive and hibernate while you're out for a coffee, anyone with a physical access can potentially rewrite your data. Of course being logged in as root makes the job infinitely easier, but one can just for example access the drive from a live environment to get the same read/write privileges. I think sudo is just a really neat mechanism to make you aware something is potentially dangerous. It adds a layer of "do you really want to do this?" as you have to consciously type your password.
If you leave a system unattended but logged in, then you are a baby and should not use Linux. Only adults should use Linux. And that actually applies to any computer system anyway - it's "Basic Security 101".
@@mrkitty777 Incorrect. Only an application with the appropriate permissions can log keys. This is why you ensure that, on multi-user systems, you only give your users the minimum permissions that they need to do their job.
@@terrydaktyllus1320 search for keylogger shell script it's only 10 lines and runs in a shell as standard user, as soon as sudo is entered it captures password and uses Firefox to submit it. Evil Friend attack since it's so easy.
Seeing is believing ~$ xinput --list AT Translated Set 2 keyboard id=15 [slave keyboard (3)] You will see devices listed, from which one is your keyboard. Then do this from the id=15 you found: $ xinput test 16 Now in another terminal window type in: $ sudo apt update [sudo] password for user: You will see that everything which you type including your passwords shows up.
Sudo can make some quick, basic commands here and there more convenient, but I think su still has its place for extended sessions and longer strings of commands, without having to "sudo" every few minutes to reauthenticate yourself. Security is no big deal to me because I live alone, but even if I didn't, no one I know who could possibly have physical access to my machine would have a clue what they're looking at. On top of that, good luck to them trying to figure out why everything they type is all jumbled--I use the Dvorak keyboard layout! And even then, back when I *did* live with other people I had a keyboard shortcut set up to quickly lock the screen, which I used every time I was about to walk away from the machine. If I didn't do this, it would still be set to automatically lock after five minutes of inactivity--so in reality, even that is not too much different than the way sudo works (only difference: sudo will lock you out after a predetermined time regardless of activity). I often use sudo for some common, short strings of commands or as quick, lazy method for one-off commands, but honestly... I prefer su for a lot of things.
At the very end: DT: "You like my work ? Want to see more videos about Linux and free and open source software ? Subscribe to DistroTube over on Patreon. Allright guys, peace!" My mind after waiting 15 seconds "Arch &Fedora"
I was wondering as well but I guess it is b/c of the logs. I started with Linux 2010 and on Debian you needed su. That's was my moment to think about the reasons :)
Debian actually have support for use sudo from installation. Just don't set a password on root user. Then login at root will be dusablee, and sudo becsetup for the user you also add. Been that for a long time, but users doesn't read the short description on that page So when you install Debian, don't set root password. And you save yourself from make up and remember two good passwors, just one
@@AndersJackson No, Anders. ABSOLUTELY DO set a root password on every system and put ONE user into the "wheel" group as the single user on the system that can "su" to root. There are fault scenarios, possibly following an unsuccessful upgrade, where the only way into a system may be by using the root account on the console. I did my Red Hat Certified Engineer certification back in 2001 and that was precisely one of the fault scenarios that we were given in the "lab practical" part of the exam.
All good points. On Ubuntu-based distros the root account is disabled by default. You can get around this by assigning it a password or you can use `sudo -i` in the terminal, but I wouldn't recommend either.
I would absolutely recommend setting a root password. I started using Linux back in 1996 and a few times I have had breakages on a system because of failed upgrades where the only way I have been able to get into a system is in single user mode (requiring a reboot and sometimes the root password) or directly as the root account in the system console. What about if all of your user home directories are on a separate hard drive that suddenly fails? If the login application cannot find your home directory then the login will fail. But if you have a "root" user, the /root home folder is never on a separate partition, so that will let you log in from the console to then do some diagnostic work.
Why sudo & not doas? lol, seriously tho to sum it all up for everyone, Sudo elevates a users privileges, still your account, su essentially switches the account from yours, to the root user for the duration of a terminal session, when you're signed into the root user you can royally f your system up if your not careful, that's why you get a warning message if you attempt to use yay, Trizen, Paru etc, advising you not to proceed as the root.
Actually, on Linux there is an almost full-proof method of physical security: you delete all panels, icons and widgets from your desktop, and then you bind all your programs, applications and commands to crazy key combinations that only you know. Ideally, you disable the mouse as well. That way, a malicious attacker will sooner kill themselves than even open a terminal on your system.
While disabling the root login works, it's not the only way to fix things. The old method can be secure if done with proper precautions. Which I used to do before sudo wasn't anything more than the ubuntu way to su. What I'm trying to say is that while disabling root login completely and using sudo fixes the issues, we had fixes for those before sudo.
You should never disable the root login. Trust me on this, there are fault scenarios that can happen on a system, particularly in a failed update to, say, PAM, that might mean the only way to get into your system might be the root login at the system console. If you cannot login to a system, then all you can do is rebuild it from scratch.
@@lawrencedoliveiro9104 So you have a system that you cannot log into because root has been disabled and now the only way to get into it is to take physical media down to the server itself to boot from that. What about if I'm a external maintainer of that system? How agreeable is the customer going to be to let me go into their equipment room with my own bootable media to go and do that? You're just creating more pain for no reason - trust me on this. I do cyber-security on my company's Linux servers on customer sites.
@@terrydaktyllus1320 Typically, nowadays, no. Since it would normally be a VM, all you have to do is put an image of something like SystemRescue into its virtual optical drive.
@@lawrencedoliveiro9104 And now what you are doing is creating a "straw man" argument that still doesn't work in real life. Firstly, I wasn't *JUST* talking about VMs, but bare metal servers also - in which case with my solution, you just need the root password, whereas with your solution, you need to get direct access to the bare metal server (that could be hundreds of miles from your location). And, rest assured, I work for a company that provides virtualised and bare metal telecoms servers - and as a third party maintainer, even if I want to install a SystemRescue ISO in the environment, I have to get approval to do it and it has to be virus checked also. All of that adds what is probably an unacceptable recovery time from a problem that might be easily resolved by just knowing the root password. I am not arguing this with you any more. I've deployed these systems in military customers and I have gone through security incident and fault scenarios with the customer in great detail. We do not normally give the customer root access to our systems, but in a specific military environment, the customer requested root access and one of the reasons for that was in case of a lockout situation. I also wrote a specific process that meant only one person in the customer environment had the authority to change the root password and we removed password aging on the root password for fear it could lock out due to lack of use, or that someone logging in at 3am to fix something might be forced to change the root password due to expiry, forget to write it down in the right place and then it would be lost. You have an extremely simplistic view of security which I also had about 15 years just before I started doing Linux server hardening. It's not just about how YOU personally would do things, it's about identifying as many of the problem scenarios as possible and writing process to deal with each one efficiently. You not opening up the root password on machines that only you maintain with probably a very small number of users may be fine for what you need - especially if you can always get quick console access to those machines. But when you work in more complicated business and commercial environments, you have to risk analyse any number of security breach or fault scenarios and come up with processes that allow you to safely restore service as quickly as possible. And one of those is to get root access quickly if it's needed, but then creating another process to ensure the root password is held securely and tightly controlled. This is not subject to further debate, this is real life - and not just about YOUR servers that YOU have full control over.
When I first started with Linux some 20 plus years ago I just ran it as root all the time. I know, bad practice but back then nothing worked well and you had to fix everything so it was just easier to not switch. To this day I forget to type sudo much of the time.
@@AndersJackson Once again, an incorrect statement. Nobody should have root if they cannot be trusted with it. But when I am hardening my clients' Red Hat servers, I can only do it as root in order to make the deep configuration changes that I need to make to secure their systems. Therefore, the fact that I have root (even temporarily while I work on their systems) means that their systems are then more secure than if I didn't have root in the first place. You seem to have this "blinkered" notion that "all root is bad" - and you're completely wrong. The "modern" philosophy of system security is "give everyone the minimum permissions to do their job" - if they need root to do their job, then they have to have it. And for the record, I started building and sysadmining UNIX systems back in around 1990 on SCO UNIX - so I make that 32 years experience in my case.
Maybe I’m wrong but I have to say this. For the server I’m not using sudo at all and this is why: 1. I’m the only one person who has the access to console 2. For remote access I use ssh key and disable password authentication 3. It’s really frustrating to type password almost all the time with every command 4. The less programs you have installed on your server the better, sudo is additional layer of security leaking, look at CVE-2021-3156, yes for the moment it’s not actual, but imagine this issue was in sudo for a many years. For desktop, I personally use sudo :)
To 'sudo' the administrator provides *own password* which should be known only to that person. To 'su -' one needs to provide *root password* which shouldn't be known to anyone. I remember the times, when the root password was written on a piece of paper, put into a stamped envelope and locked in a physical safe/vault. One could obtain the password only in case of a true emergency.
There should always be a root account on every system because certain fault conditions may mean that the only way to get into a system is using root on the system console. Yes, of course the root password should be kept very securely.
I only use su when I have to be root for a longer period of time, and especially when I have to pipe something in a protected file. I mean, when I edit some desktop files because discord thinks it's a great idea to release an force update but you don't want to have this orange logo, have fun using sudo like 50 times
If root is disabled and sudo is broken by an update, a power cut or something how do you achieve admin things, like reinstalling sudo ? Sorry if the question is stupid.
That's an excellent point, and one that I have made here several times already - especially in answer to one particular person here who thinks "root is evil" and should always be disabled. Always enable the root account with a password and just have one user that is in the "wheel" group who is allowed to su to root if necessary - anybody not in the "wheel" group cannot use su anyway. In that case, if you have a fault condition that screws up login or authentication (it does happen) then there's still a good chance that you can log in on the system console as root and fix the problem.
Most of the time I find myself using su or sudo -s, when I have to do 4 or 5 things in a row that require su privileges, at that point it's easier for me to exit back out to u privileges after I'm done than typing in sudo for every command.
People talk about how supposedly dangerous it is to log in as root but, honestly, if you understand the risks involved an are fairly careful, it really is not that dangerous at all. Of course, I say that as a former Puppy Linux user. If you're not familiar with Puppy, it's single user distro that runs root by default, where you are highly advised against running it as any other user. It is designed to be used as root and the devs explicitly tell you not to create a second, non root user.
Speaking of Puppy Linux, if someone has physical access to my laptop, they can very easily power it off, plug in a Puppy Linux USB stick (or pretty much any other distro, tbh), boot into it, mount the drive and gain read/write access to everything, or simply open GParted and wipe it. There's no preventing someone who has physical access to a device from messing with your files. There simply is not. Only solution for that is don't leave your devices unattended. And besides, even they don't go that far, just by being logged in with my default user, they can still delete everything from my home directory and the separate storage partition owned by the same user, which is just as devastating. The only things that would be protected are the exact things I wouldn't care about if they got deleted. Namely, programs I installed through pacman/pamac, which I can very easily just reinstall. Which is why I don't leave my laptop unattended.
SU is direct control of /root, sudo is given elevation user account (as sudoers) to contol the root and your account are responsible to that /root if any change happen … When the session being hijacked, the pov of adversaries try to bruteforce the account, if they managed to hijacked the session well, what kind of account they target ? Is it standard or sudoers ? What happen if you give /root, the SU directly to ssh ? While as we know application layer are much2 vulnerable to it, one of it password guessing … I recommend to understand whats use of SU and SUDO ..
And if you don't have the intelligence to work out what someone means when they say "sudo" (like "ludo") or "sudo" (like "hoodoo") then you probably shouldn't be using Linux in the first place.
Many scripts use sudo command , so uninstalling it would not be a good idea. If you personally don't want to type 'sudo' everytime you want to paru, yay or pacman, just create aliases for these cases in .bashrc or .bash-aliases.
The command after sudo will run as root (if not said something else). No need for su, and sudo bringa so many changes. Good ones It is about 30 years since I hade to use su. Then I only used it in demonstrations to show how bad it is
If it works for you, then do it that way - I work the same way, though I do understand the value of sudo in multi-user environments. But just remember that root "treats you like an adult" so if you make any mistakes at that point, then only you are to blame. BUT we all learn by making the occasional mistake!
My biggest problem with using sudo is it doesn't update the PATH to root's path when you run it. As a sysadmin, many of the tools we use for things like managing the cluster and storage have non standard paths. Maybe someone can let me know if this is possible, but it's frustrating when using sudo and getting command not found.
No sysadmin here and perhaps I got you completely wrong, but isn't it possible to add all kinds of paths to binaries in ~/.profile? Also there's a .profile in /root if you'd like to make a non-standard PATH known to root-user but I don't know what would be the point.
@@audiolatroushearetic1822 depends on how you set up sudo And that is usually a bad idea. Usually sudo reset path and other environ variables to a known state when used. Which is good. You could add /sbin and /usr/sbin to that PATH. In sudo configure file
@@michaeleagle2 Unfortunately, -E does not update the path. Even running a test with env and I can see it does not change. As root: [root@testserver ~]# env | grep PATH PATH=/usr/lib64/qt-3.3/bin:/usr/local/openssl/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin:/usr/lib/vxvm/bin:/opt/VRTSvcs/bin:/opt/VRTS/bin:/opt/VRTSvcs/rac/bin:/opt/VRTSob/bin:/opt/emc/SYMCLI/bin:/usr/local/bin/python3.6 when I run sudo -E: [user@testserver ~]$ sudo -E env | grep PATH PATH=/usr/lib64/qt-3.3/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/user/bin
Came up the same way. su - got you to root and actually exit would take you back to your user. But I agree that 'sudo' is much safer. you can also sudo su - if you have several things that need to be done under root, but one must NOT forget to exit.
At least sushi shells are less common, though still if you admin a system - have a cronjob to check for them periodically as with all admin - expect the unexpected and code around it.
If you install Debianbased systems, just not set a root password and it will set up the system for you Lock down the root account so you can't log in to it with password, and make the second user able too use sudo. Much better security
@@AndersJackson How many times are you going to repeat this rubbish, Anders? You should ALWAYS have a root account on a system and one user in the "wheel" group who can "su" to root. I have been sysadmining systems for 32 years now (2 more than you claim to) and I have had occasions where I would be locked out of a system if I could not log in directly as root in the console. A classic example is if the user home directories get deleted or corrupted, particularly if they mounted on a separate partition or hard drive. If the login system cannot find a user's home directory then login will fail. Root's home directory is under /root and is never mounted on a separate partition - therefore it may be that root login on the console may be the only way to log into a system to repair it.
oh.. sometimes I have to add a variable to my command so the superuser here in gentoo.. like USE="whatever" emerge -av whatever how would I add that with sudo? putting the var statement before the su command soes not work. And how would you prevent someone from using the root user? assignin no password to it?
I use Gentoo too - if I am doing emerges then I just do them as root. But there's no reason why you can't do them with sudo, just put sudo in front of everything at the beginning of the line.
@@BerrySwingslow I don't see why it wouldn't work: sudo USE="-vaapi" emerge mesa would be how I would enter it. But, as I said, I just do all my emerges in su anyway, so don't quote me on the above.
Or just be root. You running sudo rm *.* and root> rm *.* do the same thing In my experience, requiring sudo didn't lower mistakes. I saw people doing things like find rm(), drop databases, delete backups.
Oh, almost forgot. What does sudo provide over su using -c option ? It's still a one-time command, so the point about staying logged in as root is completely deflected. And not to mention that you don't need to bother with the wheel group and all that configuration. There's even less ways for hackers to do stuff (since you can't "su" from a bash script file, but you can sudo, if it has the permissions, say, if it's owned by your user). If you have sudo access, I don't know if disabling the root account helps that much (security-wise). You can still keep the nologin shell to keep ssh logins at bay. What am I missing ?
Every thing a hacker knows about a system, they can use And with su they know an account that can be hacked. Your root account With sudo they need to know your account, which is different from my account, that kan use sudo And when you have sudo, login with password is usually locked down. So there are no root password to create that is good. So one good password more you don't need to create and remember. As with sudo, I have that set so I need to enter my password if I don't use sudo in 2 minutes . You can demand password on each use of sudo So yes, there are several reasons sudo get you into better habbits then su.
@@AndersJackson You've contradicted yourself. A hacker needs to "know" your account in both cases. If anything "su -c" is more secure because you have to enter the root password to run that command. To do the equivalent in sudo means, depending on how it is configured, that you either don't need any password or just re-enter your password - which the hacker presumably has already due to being logged in as you.
After using su to switch users, is it better to use su to go back to your user, or should you type exit to leave the other user’s shell? I’ve always used the exit method, but I’m not sure which is best.
Each su command creates a new process. Just exit the su shell to go back to the previous one. Or if you don’t want to keep the previous one around, do “exec su” each time.
@@lawrencedoliveiro9104 I kind of thought it did something like that. From experimenting with recursion in Python, I found that running a recursive function very quickly hits limits due to having too many nested function calls. It would follow that using su to change back to the previous user could embark down that same, computationally inefficient path.
One time I have a problem with sudo. I think it was like a command concatenation where the second command was not detected as root, so doing sudo a+b just affected the first command but not the second. To make it work I have to do su root and execute it.
6:10 There is no time period using su. su - root -c "[type your command with keys here]" When attackers tries to breach security in your server, remember, that if you do not use sudo, it has to break your password AND root password, if you are using sudo - it has to break only your password.
Wow, thanks DT! I was wondering about that like a week ago. I mean, why is it "sudo" on Linux and "su" on Android? 🤔 And I thought, isn't it simpler to just type "su", but now after this video I understand why and now I hope Android becomes "sudo" instead of just "su". 😂
And that's a problem because...? What about if you have one account in the "wheel" group that has "su" access and someone has locked that account out with multiple invalid password attempts? How do you get in as root, without a root password, to reset that locked account? What about if I am hacking your system to gain entry to it via SSH? In your case, I just need your one user account password and can do all my root access "destruction" using sudo. But on my system, which doesn't allow direct root access via SSH, I have to log in with my normal user account first, then "su" to root. To get into your system to destroy it, I just need one password - but to get into mine, I need two passwords.
You still need to enter the root password using "su -c" - in sudo, you don't have to enter a password (depending on how you configure it) or you just enter your own password again.
I speak English but you might as well be speaking Chinese. I envy you. A mega-byte to me is something you get off a great white shark. I can't even copy and paste. I can find out stuff tho, that's the important bit 😉🤣👍🏻
We all started off knowing nothing. Ultimately it depends on how much time and effort you want to put into learning new things yourself. Unfortunately, you won't learn much just sitting and watching videos on YT - you need to try some of the stuff out yourself on your own systems. And be prepared to make lots of mistakes and to learn by them.
Depending how Debian (or one of it's spins) is installed the first user created may not be in the sudo-ers file and thereby have to su (to put themselves in it).
Yes, and it is easy to activate sudo and deactivate login on root user. Just don't set any password on the root account. Not hard at all, you even have one less god password to remember A win-win...
but yes, there is a disadvantage to using sudo.... namely, repetitive entering of passwords... I know, most people using terminals do that unconsciously on auto-pilot because they're used to it... But newbies might be irritated by having to reenter their pw every so often...
If your users managed to "F" up the system, then why weren't you applying proper access restrictions to them in the first place? A normal user can surely "F" up their own files and home directory, but not the entire system. I think you need to go back and look at your system-wide permissions before using sudo to give limited "as necessary" higher system permissions.
@@terrydaktyllus1320 It's their systems, I'm just tasked with bringing them up and managing them. There's a fine line between usability and security. Sure I could lock them out, but then I'd spend my day installing packages and configuring things as they like instead of actually doing what I do.
@@SyBernot Then you are not managing them very well if the users have the capability to "F" up the system - those are your words, not mine. Sure, if they delete their own files accidentally then it's up to you to find a backup and restore them - but that's not "F"-ing up the system, that's just a single user "F"-ing it up for themselves. A big difference and it's why you set permissions on a system properly.
@@terrydaktyllus1320 there's absolutely noting any of my users can do that they shouldn't be able to do in the course of their work and nothing that I couldn't recover from knowing what specifically they did. Your model of BOFH doesn't work very well in the field of research and academia the risk model just isn't the same as it would be for a bank or hospital. This is always the problem with the ultra security types. The perfect is the enemy of the good. If you don't trust the people you pay to do the right thing then why did you ever give them a login in the first place?
@@SyBernot "Your model of BOFH doesn't work very well in the field of research and academia the risk model just isn't the same as it would be for a bank or hospital." What you call "BOFH" is what I call "security best practice" and it just indicates to me how little you understand of the topic of which you now speak. Long gone are the days of a few academic and government / military sites on the ARPANet - it doesn't matter what field you work in, you are at considerable risk of cyber-attack. Yes, you're probably correct - the threat model in an academic environment is different to that of a bank or hospital, because in an academic or research environment, you are more likely to come across "well-intentioned fiddlers" who are more likely to be at an intelligence level where they might well "mess around" with internal systems. In other words, such an environment is probably more likely to suffer an internal attack than an external one - and therefore, deploying an extremely solid internal user access control methodology is MORE IMPORTANT in such an environment than, say, a bank or a hospital. "If you don't trust the people you pay to do the right thing then why did you ever give them a login in the first place?" So now you're contradicting yourself. Because in the first part you identified (probably correctly) that a research or academic environment has a very specific threat model, I agreed with you and stated that the internal attack threat is probably higher, but now you're saying "But don't worry about that threat model, we'll just trust the users anyway". So which is it? You do realise that the concept of "least privilege" is really a universal standard these days, it doesn't matter on the arena. Just give users the minimum access they need to do their jobs. And if those users are affecting the operation of infrastructure systems by virtue of too much privilege, then someone else in charge of those systems really isn't doing their job properly.
@@tatsutakamaro If you installed the system then I assume you must know the root password anyway. Once you've installed the system, your first job is to create a normal user on the system and there should always be one user in the "wheel" group who can use "su". Does that answer your question? I am not sure I understood all of it but I hope that helps.
@@terrydaktyllus1320 If I installed a system and did not install any other user, am I automatically a superuser? Even if I didnt install the sudo package?
No matter if you sudo or su, at least we can all agree that this is like a million times better than "Are you sure you want to run this as admin? [Yes] [No]"
That's what I was think of! But hey... don't forget all of the "security updates" MS force you everytime... they do it for you man! So you can have a very safe machine!
windows vibes?
"Do as I say"
You can make UAC ask a password.
@@Siger5019 the default state is the problem….
Another advantage of using sudo accounts, is accountability in seeing in the logs who did what on the system. If all actions are done by root, no matter who logged in. You have no accountability.
That is one very important reason to use sudo. It is better also in some other reason.
1. Accountability
2. You don't have a shell logged in a root and do some things when you think you are a ordinary user.
3. Access to root is just used when needed
4. A well known account, root, make it easier to hack the computer from remote.
Debian use more fine grained security, that is why they don't use wheel group. Instead divided into many different groups.
It's a No. 1 reason in a business environment.
Syslog can also log "su" activity.
@@terrydaktyllus1320 you can also disable "su" completely via pam configuration.
That's a false argument. You can always see who did log in as root to which terminal (which user in case of su or from which IP in case of SSH.) and what commands have been ran from that terminal.
The 'enhanced' security that `sudo` might provide over `su` is a fallacy in my opinion. You can still login as root with `sudo -i` or `sudo -s` depending on what you want to do. You can neutralize your system with a single command or a bunch of them. It's brute power regardless of how it was attained.
It's mainly a matter of what and how often you perform your system maintenance. Sometimes you might want to do a bunch of tasks and it's more practical to switch user as `root` and perform them.
Using `su` is not old school. It's still valid and alive today. With `su` you *need* the `root` user password. With `sudo` you use your user's password and hence you won't compromise the `root` account and you can also limit the commands a `sudoer` can execute.
Ultimately it's a matter of taste, workflow and security policies.
Most users watching DistroTube's channel are single-user desktop users so by definition they can do anything because they know the root password regardless if the user account has sudo privileges or not. sudo is more secure even on single-user systems. Once you have a normal user configured with sudo provileges, the root account can be disabled.
@@0x007A to an extent. You could use different passwords for the accounts and still plan workflows that enhance your productivity and/or enjoyment of your system. Regardless good practices can be applied to domestic systems.
And the system owner kan look in logs and see who did it.
So the use of sudo is traceble, su is not. And yes, you send the logs to another machine. That is why proper time is so important
And as you mention, sharing passwords are bad. With su you must share root password.
And you have to have another good password on the root account, unless you uses sudo
@@OctaviusPelagius people use sudo for convenience on their personal computers. I disabled the sudo password requirement because I am the only user, I have to type 'sudo ' (5 characters) anyway before the actual command to be performed so I am not likely to type 'sudo rm -rf /' by accident. The 'sudo' command provides an automatic audit trail although as the only user on the computer with a strong password the audit trail is a moot point.
If someone has physical access to my computer, they could boot from USB drive and mount the partitions - I keep sensitive data on a removable drive and it is only plugged in when needed. I used to habve my /home/username mounted from a microSD card but performance and occasional GUI freezes forced me to return to on-disk /home/username. Maybe the microSD card has problems with ext4?
says sudo security is a fallacy --> ultimately a matter of taste and security policies
Little nit pick: When using su, just do exit to go back to your previous user instead of running the command again, or else you will get nested shells
sudo is a security nightmare. There are tons of vulnerabilities connected to sudo and administering sudoers files for many users on many machines is almost impossible. So while it might make sense for home desktop users who don't know what they are doing, it doesn't for bigger companies with large number of servers and users. Also if a user have unlimited sudo access then the attacker only need to know his password to get complete control of the system instead of the root password which is usually much harder to get. The SSH argument is just showing your lack of knowledge. No one should use password authentication on SSH especially on machines connected to internet and you can disable root access on SSH level as well so no need to disable root on the system level. I work as system engineer for large companies for more than 20 years and there are many reasons why we don't use sudo.
Actually there are a number of issues with the binary (root/user) permissions method, and note that Windows really copied that system. Its not for nothing that hackers talk about "flipping the permission bit". There is no real reason to have a "super" access to everything. There are a number of ways to improve this.
1. Separate the permissions out by type and have users individually obtain each type (like access to a particular disk tree, for example).
2. Stop requiring applications be installed globally. Most applications can be installed in the user directory, meaning that installers don't need root access.
3. Give users the ability to form sandboxes easily. You are installing software. Why does the installer need root permissions? It only NEEDS permissions to its install directory and perhaps a few other resources.
4. Remove the "flip permissions" ability. The OS should not give every user in the system the ability to boost their access level. A better model is to have processes be able to restrict access, but never add it. Thus the root spawns user logins, and a user process can execute a subprocess with less permissions that that, but no process can boost their access back up again. It means if you want higher level access, you have to use a higher level account. The improvement is that there is no way to increase your access level programmatic ally via the OS. None.
What would you use instead I would like to know for research purposes
As always writing a comment to support the channel
Regarding logging in as another user (either fully, or just in a terminal session) is that yourself can be a danger. Say, you do take a break and come back some time later and forget that you're logged in as root (I know, in terminals you have a different prompt, but not everybody is used to that).
And if you forget that you're logged as root, you might do things that you don't want to do. Commands that you run and that create files or folders, they will be owned by root. And you might find out later that your user doesn't have access to them or that some daemon cannot interact with said files anymore or things of that nature.
Yes, running dolphin or nautilus as a user with elevation creates files in a user directory which can make a user account inaccessible e.g.
Some who forgets they are logged in as root should not have access as root. Root is for adults, not babies.
@@mrkitty777 That doesn't make any sense as a statement. Provide a specific scenario where that is a problem.
The sudoers file is a mighty tool.
You could restrict users to specific programms as root etc.
But it's best suited for server usage.
But if you're using just a single desktop system, use doas.
Why use doas when you have already sudo and everyone is familiar with it. I used doas for some time but I don't see any benefit.
nah, the whole argument for doas is removing complexity and potential vulnerabilities added by features you dont need,
but at that point, why even use doas?
just cause its less likely doesnt mean it cant contain vulnerabilities, so why not go the extra step and remove that too?
I used to use doas but then needed a configuration program that relies on sudo. Unfortunately it still didn't work well after patching it myself.
@@coolbean9880 That's a silly argument because what you're saying is that you can't trust your software because it adds complexity, vulnerabilities and features that you don't need. Okay, it's a "strategy", I guess, but then the only thing you can trust is you, as the user. And if you trust "you" completely, then just use the root account all of the time - and don't even mess with "su", "sudo", "doas" or even normal user accounts, all of which (by your definition and not mine) add complexity, vulnerabilities and features you don't need.
@@terrydaktyllus1320 why would i need any more confidence to use su, then exit when im done compared to just using sudo/doas?
the effect is ultimately the same and on your home computer the odds of someone messing with your home computer after youve left with a terminal still logged into root are typically limited to pets and children, both quite easily thwarted with a screenlocker
im simply taking the logic to a more extreme extent specifically to point out how the train of thought behind using doas on systems that use it natively are either a. paranoid bullshit or b. trying to flex because you're technically protected against incredibly rare user previlege escalation exploits in a single application on your computer (though a lot of the latter dont even end up actually removing sudo from their system so it often remains accessible using it's absolute path)
My first distro was Slackware. I remember using root user account a lot, and later using su and much later sudo.
Same here, used Slackware from 98 - 2008. Even with sudo my level of discipline and focus still remains over a decade later. It has become second nature to reconfirm my decisions a few times before hitting enter.
Have u used Slackware 15?
@@d_sanu No. Once I switched from Slackware to Debian I haven't done much distro-jumping. Is it good?
If some bad agent gets physical access to your computer, surely you got bigger problems than file permissions
That said sudo is a great tool to protect the user from himself. Just the extra confirmation prompt alone already saved me from doing some undesirable actions
A terminal is a basic thing that is almost always open on my computers, often with multiple tabs with SSH sessions and what not. You will also most of the time, find one or two 'sudo -s' tabs. If I need to do more than a single command as root, I always launch a root session. The advantage of sudo is not that su allows someone to sit down at your computer. The worst damage to my system would be to delete my personal files, no root required. If they only break the system, I can simply restore it. Also, I know who is in my house at a given time and I switch off or lock my computers when not using them.
The advantage of sudo over su is the fact that you can disable root login. Anyone requiring root will have to go through sudo initially to do so. On a personal system with a single user, I don't think this makes any difference at all. If you have a user password, that password can easily be used twice using sudo. But on a corporate network this will make a huge difference. Each user will have there own separate password, logs can be traced much easier, temperately access can be granted without exposing some shared super secret password etc.
I'm using Doas instead of Sudo, I regret nothing. Also having to set up the config yourself is a level of transparency I can subscribe to. Literally one line and less than fifteen characters across is enough to keep you from borking your single-user setup.
With respect, in Gentoo Linux I just make a simple removal of a "#" at the beginning of a line in /etc/sudoers to allow me, as a member of the "wheel" group, to use sudo. So I am doing it in 14 less characters than you are in "doas".
@@terrydaktyllus1320 aight.
@@phonewithoutquestion80 I don't understand. I speak and write a language known as "English" if that helps.
@@terrydaktyllus1320 a(lr)ight
@@multicat2742 So was that just a mistake or some new "hipster" cool word that I supposed to know the meaning of?
I remember the su command from my Red Hat Linux days. Absolutely correct, if you logged in as root user, basically anyone with access to the terminal is logged in as the root user.
That's why "Basic Security 101" says "Don't leave your PC unattended with a logged in terminal" and "make sure you configure terminal timeouts". If you don't understand those two basic concepts, you should be nowhere near a root terminal, because you are not an adult.
@@terrydaktyllus1320 more like a typical Windows user, but you are correct and I agree with your point.
@@keylowmike85 I don't use Windows these days (I kicked that crap out of my life when Windows 7 support ended) but I do wonder about those people that think Windows 10 is a usable OS - when all I see is a Microsoft advertising platform that steals all of your personal data, takes charge of the PC you bought with your own money and then "leases" it back to you as it sees fit.
They talk about the "Software As A Service" model, but Microsoft goes one better and makes it "Your Hardware As A Service".
Good riddance to my Microsoft abuser.
@@terrydaktyllus1320 I, unfortunately, can't remove Windows because my work laptop is running Windows 10. But my personal ThinkPad is running Linux. I've always been drawn to Linux because it offered freedom.
@@keylowmike85 My day job is with Linux servers, my work gives me two laptops - one with Linux on it, the other with Windows 10 on it. (The Linux one is a Thinkpad, plus I have a large collection of Thinkpads at home, all running Gentoo Linux.) The Windows laptop sits in a corner gathering dust except for 30 minutes on a Friday when I have to use it for a time reporting application that only seems to work on Windows.
I have configured my network to put the Windows laptop in its own VLAN on its own so that it cannot communicate with the rest of my home network and it can only connect to the outside world when it's VPN is active to my work network. I do not allow that disgusting operating system anywhere near my home network - even the wife uses only CrApple devices which are slightly better than Windows 10.
Another very thoughtful video. Thanks DT!
love that cmatrix
You can also use sudo to allow certain commands to be run as a different user. For a single user system it may not be the most important use, but for a multi-user system it can be handy.
I wanted to note something about the su method. Both here and in another video of yours I remember you saying something along the lines of "su to the root user and then su back to your regular user". That is even worse of a security risk! Su opens a new shell instance with the user you specify, so you end up with nested shells, meaning that after you su back to the regular user, a mailcious attacker could just type "exit" to quit the regular shell and get back to the parent root shell!
Example:
$ echo $UID
1000 (regular user)
$ su root
Password: ...
# echo $UID
0 (root user)
# su user
$ echo $UID
1000 (regular user)
$ exit
# echo $UID
0 (back to root user!)
# exit
$ echo $UID
1000 (back to regular user)
$ exit
shell exits
Instead of doing su user, simply exit the root shell.
$ echo $UID
1000 (regular user)
$ su root
Password: ...
# echo $UID
0 (root user)
# exit
$ echo $UID
1000 (back to regular user)
$ exit
shell exits
At a previous job, our Linux setup was a little weird. We had a service account on the machine that 'owned' the webserver or DB server, etc, application, but we had to log in with our own user account.
By adding the user accounts to the sudoers file and only allowing certain commands -- sudo su [account] and sudo su - [account] -- we could share the service account without having either the root password nor the service account password.
OpenBSD's doas is much simpler than sudo.
I do remember, back in the days, also the toor account used to split root.
Last, nowdays alot of systems have predictable users like mysql,backup,postgres,etc.
I run (Gentoo) Linux at home and work on (Red Hat) Linux servers. I have taught myself the "lowest common denominator" tools for system administration, maintenance and hardening - "learn one thing and use it everywhere" is my mantra. Vim, sed, awk, bash, etc. may seem "boring" to some people but they are mainstay applications that are installed everywhere.
As far as I am concerned "doas" is just another application for "fashionistas" that doesn't really offer anything more, from a functional perspective, that "sudo" does - if it did, I would have now become the de-facto replacement for sudo.
By all means run your "doas", "fish" or "zsh" shells, and your other "apps to make me look cool to my peers" on your own systems, but don't then blame anyone else but yourself if you get to a time where you're working on someone else's systems and are not allowed to install your "fashionista" apps on them.
there is also a port of doas called OpenDoas
sudo offers more control.
Having been a Unix admin, i did indeed wonder. Thanks!
I don't buy the "physical access" argument. Unless you fully encrypt your hard drive and hibernate while you're out for a coffee, anyone with a physical access can potentially rewrite your data. Of course being logged in as root makes the job infinitely easier, but one can just for example access the drive from a live environment to get the same read/write privileges.
I think sudo is just a really neat mechanism to make you aware something is potentially dangerous. It adds a layer of "do you really want to do this?" as you have to consciously type your password.
Any application in X server can use xinput to log keys.
If you leave a system unattended but logged in, then you are a baby and should not use Linux. Only adults should use Linux.
And that actually applies to any computer system anyway - it's "Basic Security 101".
@@mrkitty777 Incorrect. Only an application with the appropriate permissions can log keys. This is why you ensure that, on multi-user systems, you only give your users the minimum permissions that they need to do their job.
@@terrydaktyllus1320 search for keylogger shell script it's only 10 lines and runs in a shell as standard user, as soon as sudo is entered it captures password and uses Firefox to submit it. Evil Friend attack since it's so easy.
Seeing is believing
~$ xinput --list
AT Translated Set 2 keyboard id=15 [slave keyboard (3)]
You will see devices listed, from which one is your keyboard.
Then do this from the id=15 you found:
$ xinput test 16
Now in another terminal window type in:
$ sudo apt update
[sudo] password for user:
You will see that everything which you type including your passwords
shows up.
Good to know. Thank you. I was curious about this but never looked into it. Makes good sense.
Hey dt, when are you going to continue your rap career I would really like to see some gnu/Linux bars.
Thanks. I couldn't understand for a long time why sudo doesn't work on some OSs.
Sudo can make some quick, basic commands here and there more convenient, but I think su still has its place for extended sessions and longer strings of commands, without having to "sudo" every few minutes to reauthenticate yourself.
Security is no big deal to me because I live alone, but even if I didn't, no one I know who could possibly have physical access to my machine would have a clue what they're looking at. On top of that, good luck to them trying to figure out why everything they type is all jumbled--I use the Dvorak keyboard layout!
And even then, back when I *did* live with other people I had a keyboard shortcut set up to quickly lock the screen, which I used every time I was about to walk away from the machine. If I didn't do this, it would still be set to automatically lock after five minutes of inactivity--so in reality, even that is not too much different than the way sudo works (only difference: sudo will lock you out after a predetermined time regardless of activity).
I often use sudo for some common, short strings of commands or as quick, lazy method for one-off commands, but honestly... I prefer su for a lot of things.
sudo -i, sudo -s, will work to launch root's default shell. sudo {sh,bash} will work to start a shell when you need to act as root.
At the very end:
DT: "You like my work ? Want to see more videos about Linux and free and open source software ? Subscribe to DistroTube over on Patreon. Allright guys, peace!"
My mind after waiting 15 seconds "Arch &Fedora"
I was wondering as well but I guess it is b/c of the logs.
I started with Linux 2010 and on Debian you needed su. That's was my moment to think about the reasons :)
Debian actually have support for use sudo from installation.
Just don't set a password on root user. Then login at root will be dusablee, and sudo becsetup for the user you also add.
Been that for a long time, but users doesn't read the short description on that page
So when you install Debian, don't set root password. And you save yourself from make up and remember two good passwors, just one
@@AndersJackson Thank you for your advice! o/
@@AndersJackson No, Anders. ABSOLUTELY DO set a root password on every system and put ONE user into the "wheel" group as the single user on the system that can "su" to root.
There are fault scenarios, possibly following an unsuccessful upgrade, where the only way into a system may be by using the root account on the console. I did my Red Hat Certified Engineer certification back in 2001 and that was precisely one of the fault scenarios that we were given in the "lab practical" part of the exam.
I started with Linux in 1999 with Redhat and sudo was part of the experience
sudo su
Niooooo......
Since I switched to Linux, Phil Collins' Sussudio never sounds the same anymore 🤣😭
Never had such concerns, most of the time I am just using those two together, i.e. "sudo su".
All good points.
On Ubuntu-based distros the root account is disabled by default. You can get around this by assigning it a password or you can use `sudo -i` in the terminal, but I wouldn't recommend either.
I would absolutely recommend setting a root password. I started using Linux back in 1996 and a few times I have had breakages on a system because of failed upgrades where the only way I have been able to get into a system is in single user mode (requiring a reboot and sometimes the root password) or directly as the root account in the system console.
What about if all of your user home directories are on a separate hard drive that suddenly fails? If the login application cannot find your home directory then the login will fail. But if you have a "root" user, the /root home folder is never on a separate partition, so that will let you log in from the console to then do some diagnostic work.
Why sudo & not doas? lol, seriously tho to sum it all up for everyone, Sudo elevates a users privileges, still your account, su essentially switches the account from yours, to the root user for the duration of a terminal session, when you're signed into the root user you can royally f your system up if your not careful, that's why you get a warning message if you attempt to use yay, Trizen, Paru etc, advising you not to proceed as the root.
This video made me remember the time I used Su and after changing users, sudo ,lol
Actually, on Linux there is an almost full-proof method of physical security: you delete all panels, icons and widgets from your desktop, and then you bind all your programs, applications and commands to crazy key combinations that only you know. Ideally, you disable the mouse as well. That way, a malicious attacker will sooner kill themselves than even open a terminal on your system.
Hey DT what do you think of using a normal camera as a webcam? And what camera do you use?
The only Linux command someone wrote a song about
Actually not. There are several songs about Emacs. 😎🙂🙃☀️🤩
While disabling the root login works, it's not the only way to fix things. The old method can be secure if done with proper precautions. Which I used to do before sudo wasn't anything more than the ubuntu way to su. What I'm trying to say is that while disabling root login completely and using sudo fixes the issues, we had fixes for those before sudo.
You should never disable the root login. Trust me on this, there are fault scenarios that can happen on a system, particularly in a failed update to, say, PAM, that might mean the only way to get into your system might be the root login at the system console. If you cannot login to a system, then all you can do is rebuild it from scratch.
Disabling root login is no biggie. If your system is stuffed, boot from a SystemRescue volume, and fix things that way.
@@lawrencedoliveiro9104 So you have a system that you cannot log into because root has been disabled and now the only way to get into it is to take physical media down to the server itself to boot from that. What about if I'm a external maintainer of that system? How agreeable is the customer going to be to let me go into their equipment room with my own bootable media to go and do that?
You're just creating more pain for no reason - trust me on this. I do cyber-security on my company's Linux servers on customer sites.
@@terrydaktyllus1320 Typically, nowadays, no. Since it would normally be a VM, all you have to do is put an image of something like SystemRescue into its virtual optical drive.
@@lawrencedoliveiro9104 And now what you are doing is creating a "straw man" argument that still doesn't work in real life.
Firstly, I wasn't *JUST* talking about VMs, but bare metal servers also - in which case with my solution, you just need the root password, whereas with your solution, you need to get direct access to the bare metal server (that could be hundreds of miles from your location).
And, rest assured, I work for a company that provides virtualised and bare metal telecoms servers - and as a third party maintainer, even if I want to install a SystemRescue ISO in the environment, I have to get approval to do it and it has to be virus checked also. All of that adds what is probably an unacceptable recovery time from a problem that might be easily resolved by just knowing the root password.
I am not arguing this with you any more. I've deployed these systems in military customers and I have gone through security incident and fault scenarios with the customer in great detail. We do not normally give the customer root access to our systems, but in a specific military environment, the customer requested root access and one of the reasons for that was in case of a lockout situation.
I also wrote a specific process that meant only one person in the customer environment had the authority to change the root password and we removed password aging on the root password for fear it could lock out due to lack of use, or that someone logging in at 3am to fix something might be forced to change the root password due to expiry, forget to write it down in the right place and then it would be lost.
You have an extremely simplistic view of security which I also had about 15 years just before I started doing Linux server hardening. It's not just about how YOU personally would do things, it's about identifying as many of the problem scenarios as possible and writing process to deal with each one efficiently.
You not opening up the root password on machines that only you maintain with probably a very small number of users may be fine for what you need - especially if you can always get quick console access to those machines.
But when you work in more complicated business and commercial environments, you have to risk analyse any number of security breach or fault scenarios and come up with processes that allow you to safely restore service as quickly as possible. And one of those is to get root access quickly if it's needed, but then creating another process to ensure the root password is held securely and tightly controlled.
This is not subject to further debate, this is real life - and not just about YOUR servers that YOU have full control over.
When I first started with Linux some 20 plus years ago I just ran it as root all the time. I know, bad practice but back then nothing worked well and you had to fix everything so it was just easier to not switch. To this day I forget to type sudo much of the time.
Was a sysadm with 30 years experiance back then.
And if you run as root, no wonder norhing worked for you.
@@AndersJackson Indeed, because you know, hardware isn't meant for root.
@@AndersJackson Once again, an incorrect statement. Nobody should have root if they cannot be trusted with it. But when I am hardening my clients' Red Hat servers, I can only do it as root in order to make the deep configuration changes that I need to make to secure their systems. Therefore, the fact that I have root (even temporarily while I work on their systems) means that their systems are then more secure than if I didn't have root in the first place.
You seem to have this "blinkered" notion that "all root is bad" - and you're completely wrong.
The "modern" philosophy of system security is "give everyone the minimum permissions to do their job" - if they need root to do their job, then they have to have it.
And for the record, I started building and sysadmining UNIX systems back in around 1990 on SCO UNIX - so I make that 32 years experience in my case.
Maybe I’m wrong but I have to say this.
For the server I’m not using sudo at all and this is why:
1. I’m the only one person who has the access to console
2. For remote access I use ssh key and disable password authentication
3. It’s really frustrating to type password almost all the time with every command
4. The less programs you have installed on your server the better, sudo is additional layer of security leaking, look at CVE-2021-3156, yes for the moment it’s not actual, but imagine this issue was in sudo for a many years.
For desktop, I personally use sudo :)
Hey DT, are you still using doas ?
Often? Why not Always!
sudo su
This is a possible security hole of the wheel users.
To 'sudo' the administrator provides *own password* which should be known only to that person. To 'su -' one needs to provide *root password* which shouldn't be known to anyone. I remember the times, when the root password was written on a piece of paper, put into a stamped envelope and locked in a physical safe/vault. One could obtain the password only in case of a true emergency.
There should always be a root account on every system because certain fault conditions may mean that the only way to get into a system is using root on the system console. Yes, of course the root password should be kept very securely.
I only use su when I have to be root for a longer period of time, and especially when I have to pipe something in a protected file.
I mean, when I edit some desktop files because discord thinks it's a great idea to release an force update but you don't want to have this orange logo, have fun using sudo like 50 times
If root is disabled and sudo is broken by an update, a power cut or something how do you achieve admin things, like reinstalling sudo ? Sorry if the question is stupid.
That's an excellent point, and one that I have made here several times already - especially in answer to one particular person here who thinks "root is evil" and should always be disabled.
Always enable the root account with a password and just have one user that is in the "wheel" group who is allowed to su to root if necessary - anybody not in the "wheel" group cannot use su anyway.
In that case, if you have a fault condition that screws up login or authentication (it does happen) then there's still a good chance that you can log in on the system console as root and fix the problem.
Most of the time I find myself using su or sudo -s, when I have to do 4 or 5 things in a row that require su privileges, at that point it's easier for me to exit back out to u privileges after I'm done than typing in sudo for every command.
The cmatrix in the background stops right before the bottom, and it's really bugging me
About sudo - sudo remembers the password for X minutes, not that you don't need to invoke sudo anymore in that time period ;)
Thank you for this topic, but subject not covered) Is only sudo? Is no alternatives? How about super, calife, ssu and others?
People talk about how supposedly dangerous it is to log in as root but, honestly, if you understand the risks involved an are fairly careful, it really is not that dangerous at all.
Of course, I say that as a former Puppy Linux user. If you're not familiar with Puppy, it's single user distro that runs root by default, where you are highly advised against running it as any other user. It is designed to be used as root and the devs explicitly tell you not to create a second, non root user.
Speaking of Puppy Linux, if someone has physical access to my laptop, they can very easily power it off, plug in a Puppy Linux USB stick (or pretty much any other distro, tbh), boot into it, mount the drive and gain read/write access to everything, or simply open GParted and wipe it.
There's no preventing someone who has physical access to a device from messing with your files. There simply is not. Only solution for that is don't leave your devices unattended.
And besides, even they don't go that far, just by being logged in with my default user, they can still delete everything from my home directory and the separate storage partition owned by the same user, which is just as devastating.
The only things that would be protected are the exact things I wouldn't care about if they got deleted. Namely, programs I installed through pacman/pamac, which I can very easily just reinstall.
Which is why I don't leave my laptop unattended.
Cus I forget to set up sudo file, and it can take months before I am ever annoyed enough by it to do it.
Aren't there some commands (programs) that literally won't run as root, thus making sudo (or doas) necessary?
SU is direct control of /root,
sudo is given elevation user account (as sudoers) to contol the root and your account are responsible to that /root if any change happen …
When the session being hijacked, the pov of adversaries try to bruteforce the account, if they managed to hijacked the session well, what kind of account they target ? Is it standard or sudoers ?
What happen if you give /root, the SU directly to ssh ?
While as we know application layer are much2 vulnerable to it, one of it password guessing …
I recommend to understand whats use of SU and SUDO ..
Ah yes, finally a man of culture who doesn't pronounce "sudo" as "pseudo."
And if you don't have the intelligence to work out what someone means when they say "sudo" (like "ludo") or "sudo" (like "hoodoo") then you probably shouldn't be using Linux in the first place.
Isn't uninstalling sudo package breaks using of AURs via paru or yay? Or it will ask root passwd instead of user passwd?
Many scripts use sudo command , so uninstalling it would not be a good idea. If you personally don't want to type 'sudo' everytime you want to paru, yay or pacman, just create aliases for these cases in .bashrc or .bash-aliases.
The command after sudo will run as root (if not said something else).
No need for su, and sudo bringa so many changes. Good ones
It is about 30 years since I hade to use su. Then I only used it in demonstrations to show how bad it is
Fun fact: Sudo in spanish means "I sweat".
I'm just always logged in as groot. It's more convenient.
On Mageia i just use su. Still learning commands, but using su instead of sudo actually for me works all the time compared to sudo.
If it works for you, then do it that way - I work the same way, though I do understand the value of sudo in multi-user environments. But just remember that root "treats you like an adult" so if you make any mistakes at that point, then only you are to blame. BUT we all learn by making the occasional mistake!
My biggest problem with using sudo is it doesn't update the PATH to root's path when you run it. As a sysadmin, many of the tools we use for things like managing the cluster and storage have non standard paths. Maybe someone can let me know if this is possible, but it's frustrating when using sudo and getting command not found.
/sbin
Have you tried sudo -E
No sysadmin here and perhaps I got you completely wrong, but isn't it possible to add all kinds of paths to binaries in ~/.profile? Also there's a .profile in /root if you'd like to make a non-standard PATH known to root-user but I don't know what would be the point.
@@audiolatroushearetic1822 depends on how you set up sudo
And that is usually a bad idea.
Usually sudo reset path and other environ variables to a known state when used. Which is good. You could add /sbin and /usr/sbin to that PATH. In sudo configure file
@@michaeleagle2 Unfortunately, -E does not update the path. Even running a test with env and I can see it does not change.
As root:
[root@testserver ~]# env | grep PATH
PATH=/usr/lib64/qt-3.3/bin:/usr/local/openssl/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin:/usr/lib/vxvm/bin:/opt/VRTSvcs/bin:/opt/VRTS/bin:/opt/VRTSvcs/rac/bin:/opt/VRTSob/bin:/opt/emc/SYMCLI/bin:/usr/local/bin/python3.6
when I run sudo -E:
[user@testserver ~]$ sudo -E env | grep PATH
PATH=/usr/lib64/qt-3.3/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/user/bin
Came up the same way. su - got you to root and actually exit would take you back to your user. But I agree that 'sudo' is much safer. you can also sudo su - if you have several things that need to be done under root, but one must NOT forget to exit.
Pointless to use both. Just use one or the other.
Want a root shell? “sudo /bin/bash”, or even “exec sudo /bin/bash”.
why sudo or su when you can doas, sounds much cooler so it's obviously better
PCLinuxOS still doesn't include sudo.
Should you disable root for a personal desktop machine?
Damn, I've been pronouncing it wrong my entire life!
At least sushi shells are less common, though still if you admin a system - have a cronjob to check for them periodically as with all admin - expect the unexpected and code around it.
Is only recommended to disable the root user in servers or in a normal desktop is also recommended?
Hey DT, when i use sudo with a command, which password does it ask for? my user password or the root user password?
good video
The user password.
If you install Debianbased systems, just not set a root password and it will set up the system for you
Lock down the root account so you can't log in to it with password, and make the second user able too use sudo.
Much better security
@@AndersJackson How many times are you going to repeat this rubbish, Anders? You should ALWAYS have a root account on a system and one user in the "wheel" group who can "su" to root. I have been sysadmining systems for 32 years now (2 more than you claim to) and I have had occasions where I would be locked out of a system if I could not log in directly as root in the console.
A classic example is if the user home directories get deleted or corrupted, particularly if they mounted on a separate partition or hard drive. If the login system cannot find a user's home directory then login will fail.
Root's home directory is under /root and is never mounted on a separate partition - therefore it may be that root login on the console may be the only way to log into a system to repair it.
su is what i use when i need to sit in a directory that my normal user wont have permissions for
I've always liked sudo since the joke, "Sudo, make me a sandwich!". ROFL!!
oh.. sometimes I have to add a variable to my command so the superuser here in gentoo.. like
USE="whatever" emerge -av whatever
how would I add that with sudo? putting the var statement before the su command soes not work.
And how would you prevent someone from using the root user? assignin no password to it?
I use Gentoo too - if I am doing emerges then I just do them as root. But there's no reason why you can't do them with sudo, just put sudo in front of everything at the beginning of the line.
@@terrydaktyllus1320 but it won't read that use variable being root/rude 🤪
Using sudo you know like I wrote the line
@@BerrySwingslow I don't see why it wouldn't work:
sudo USE="-vaapi" emerge mesa
would be how I would enter it.
But, as I said, I just do all my emerges in su anyway, so don't quote me on the above.
@@terrydaktyllus1320 thank you, I'll give it a try anyway 😉
Or just be root. You running sudo rm *.* and root> rm *.* do the same thing
In my experience, requiring sudo didn't lower mistakes. I saw people doing things like find rm(), drop databases, delete backups.
How do you make your monitor display that on ypur screen
What if the user with sudo privileges [ ( ALL:ALL) ALL ] gets compromised? What if and how, the user's password gets compromised?!!
You didn't mention why it's a good idea to use the same password for root and the main user. For example when you install a VM.
sudo su
There now everyone is happy.
Oh, almost forgot. What does sudo provide over su using -c option ? It's still a one-time command, so the point about staying logged in as root is completely deflected. And not to mention that you don't need to bother with the wheel group and all that configuration.
There's even less ways for hackers to do stuff (since you can't "su" from a bash script file, but you can sudo, if it has the permissions, say, if it's owned by your user).
If you have sudo access, I don't know if disabling the root account helps that much (security-wise). You can still keep the nologin shell to keep ssh logins at bay.
What am I missing ?
Every thing a hacker knows about a system, they can use
And with su they know an account that can be hacked. Your root account
With sudo they need to know your account, which is different from my account, that kan use sudo
And when you have sudo, login with password is usually locked down. So there are no root password to create that is good.
So one good password more you don't need to create and remember.
As with sudo, I have that set so I need to enter my password if I don't use sudo in 2 minutes . You can demand password on each use of sudo
So yes, there are several reasons sudo get you into better habbits then su.
@@AndersJackson You've contradicted yourself. A hacker needs to "know" your account in both cases. If anything "su -c" is more secure because you have to enter the root password to run that command.
To do the equivalent in sudo means, depending on how it is configured, that you either don't need any password or just re-enter your password - which the hacker presumably has already due to being logged in as you.
After using su to switch users, is it better to use su to go back to your user, or should you type exit to leave the other user’s shell? I’ve always used the exit method, but I’m not sure which is best.
Each su command creates a new process. Just exit the su shell to go back to the previous one. Or if you don’t want to keep the previous one around, do “exec su” each time.
@@lawrencedoliveiro9104 I kind of thought it did something like that. From experimenting with recursion in Python, I found that running a recursive function very quickly hits limits due to having too many nested function calls. It would follow that using su to change back to the previous user could embark down that same, computationally inefficient path.
One time I have a problem with sudo. I think it was like a command concatenation where the second command was not detected as root, so doing sudo a+b just affected the first command but not the second. To make it work I have to do su root and execute it.
6:10 There is no time period using su. su - root -c "[type your command with keys here]"
When attackers tries to breach security in your server, remember, that if you do not use sudo, it has to break your password AND root password, if you are using sudo - it has to break only your password.
Holup everyone will disable root account in server. I mean why they need to break root passwd
@@lilith1504 Why do you disable root account? It is actually makes no sense, because root should exist to exec tasks with highest privileges.
"Laughs in Doas"
doas :]
Wow, thanks DT! I was wondering about that like a week ago. I mean, why is it "sudo" on Linux and "su" on Android? 🤔
And I thought, isn't it simpler to just type "su", but now after this video I understand why and now I hope Android becomes "sudo" instead of just "su". 😂
isn't it pronounced sudo with an o and not a u at the end...
"sudo" stands for "super user do". Hence....SUE-due.
Because su needs you to set a root password.
And that's a problem because...?
What about if you have one account in the "wheel" group that has "su" access and someone has locked that account out with multiple invalid password attempts? How do you get in as root, without a root password, to reset that locked account?
What about if I am hacking your system to gain entry to it via SSH? In your case, I just need your one user account password and can do all my root access "destruction" using sudo. But on my system, which doesn't allow direct root access via SSH, I have to log in with my normal user account first, then "su" to root.
To get into your system to destroy it, I just need one password - but to get into mine, I need two passwords.
Was the -c flag for su not a thing back in the day?
what about su -c "command"? it just executes a single command as root
You still need to enter the root password using "su -c" - in sudo, you don't have to enter a password (depending on how you configure it) or you just enter your own password again.
Then there's people who do sudo su
I did not installed sudo.
Or i su or i don't.
Is it safer, no.
Good video.
I speak English but you might as well be speaking Chinese. I envy you. A mega-byte to me is something you get off a great white shark. I can't even copy and paste. I can find out stuff tho, that's the important bit 😉🤣👍🏻
Ctrl+C to copy, Ctrl+V to paste.
We all started off knowing nothing. Ultimately it depends on how much time and effort you want to put into learning new things yourself. Unfortunately, you won't learn much just sitting and watching videos on YT - you need to try some of the stuff out yourself on your own systems. And be prepared to make lots of mistakes and to learn by them.
If one isn't work use another , the end.
Depending how Debian (or one of it's spins) is installed the first user created may not be in the sudo-ers file and thereby have to su (to put themselves in it).
Yes, and it is easy to activate sudo and deactivate login on root user.
Just don't set any password on the root account. Not hard at all, you even have one less god password to remember
A win-win...
but yes, there is a disadvantage to using sudo.... namely, repetitive entering of passwords...
I know, most people using terminals do that unconsciously on auto-pilot because they're used to it... But newbies might be irritated by having to reenter their pw every so often...
The main reason for forcing sudo is so I can see what my users did to F up the system.
man sudoreplay
If your users managed to "F" up the system, then why weren't you applying proper access restrictions to them in the first place? A normal user can surely "F" up their own files and home directory, but not the entire system. I think you need to go back and look at your system-wide permissions before using sudo to give limited "as necessary" higher system permissions.
@@terrydaktyllus1320 It's their systems, I'm just tasked with bringing them up and managing them. There's a fine line between usability and security. Sure I could lock them out, but then I'd spend my day installing packages and configuring things as they like instead of actually doing what I do.
@@SyBernot Then you are not managing them very well if the users have the capability to "F" up the system - those are your words, not mine.
Sure, if they delete their own files accidentally then it's up to you to find a backup and restore them - but that's not "F"-ing up the system, that's just a single user "F"-ing it up for themselves.
A big difference and it's why you set permissions on a system properly.
@@terrydaktyllus1320 there's absolutely noting any of my users can do that they shouldn't be able to do in the course of their work and nothing that I couldn't recover from knowing what specifically they did. Your model of BOFH doesn't work very well in the field of research and academia the risk model just isn't the same as it would be for a bank or hospital. This is always the problem with the ultra security types. The perfect is the enemy of the good. If you don't trust the people you pay to do the right thing then why did you ever give them a login in the first place?
@@SyBernot "Your model of BOFH doesn't work very well in the field of research and academia the risk model just isn't the same as it would be for a bank or hospital."
What you call "BOFH" is what I call "security best practice" and it just indicates to me how little you understand of the topic of which you now speak.
Long gone are the days of a few academic and government / military sites on the ARPANet - it doesn't matter what field you work in, you are at considerable risk of cyber-attack.
Yes, you're probably correct - the threat model in an academic environment is different to that of a bank or hospital, because in an academic or research environment, you are more likely to come across "well-intentioned fiddlers" who are more likely to be at an intelligence level where they might well "mess around" with internal systems.
In other words, such an environment is probably more likely to suffer an internal attack than an external one - and therefore, deploying an extremely solid internal user access control methodology is MORE IMPORTANT in such an environment than, say, a bank or a hospital.
"If you don't trust the people you pay to do the right thing then why did you ever give them a login in the first place?"
So now you're contradicting yourself. Because in the first part you identified (probably correctly) that a research or academic environment has a very specific threat model, I agreed with you and stated that the internal attack threat is probably higher, but now you're saying "But don't worry about that threat model, we'll just trust the users anyway".
So which is it? You do realise that the concept of "least privilege" is really a universal standard these days, it doesn't matter on the arena. Just give users the minimum access they need to do their jobs.
And if those users are affecting the operation of infrastructure systems by virtue of too much privilege, then someone else in charge of those systems really isn't doing their job properly.
Can you make a video about shourtcut video editor?
Why "su" when you can litigate?
Can you explain what you mean? I'm interested
@@bvbianca It's a pun on the word sue.
@@Saztog1425 How?
don't forget in addition to ubuntu, debian has sudo group.
Is "sudo" something that should be installed? I thought it's just a bash command...
"sudo" is a separate Linux package, it is not a bash built-in.
@@terrydaktyllus1320 well, is it already preinstalled in some distros? Which ones? Mint/ Ubuntu/ Debian?
@@terrydaktyllus1320 And what if it is not installed? Is then a user who installed the whole system considered a superuser or a usual user?
@@tatsutakamaro If you installed the system then I assume you must know the root password anyway.
Once you've installed the system, your first job is to create a normal user on the system and there should always be one user in the "wheel" group who can use "su".
Does that answer your question? I am not sure I understood all of it but I hope that helps.
@@terrydaktyllus1320 If I installed a system and did not install any other user, am I automatically a superuser? Even if I didnt install the sudo package?
Normally in old days we sucked (su -c)