Please note that I'm not a certified security expert, although I do have large experience in cleaning PCs of people from trashware and malware (mostly with windows, but the same reasoning applies to Linux).
Also to a long post I answer with an even longer one lol.
linx255 wrote:I suppose I could add programs to the sudo list, but sometimes I need to actually enable root. Can you give me a few examples of the biggest threats of extending root access?
The malware category called "rootkits". Linux is not immune to malware, it is just immune to (most) Windos malware, which is NOT the same thing.
By how linux is made, unless something has root access, it's not going to be able to do much (can still nuke the PC if done cleverly but that's the less sophisticated and less dangerous category of malware around). On Windows it's amazing what malware can do even without admin/root privileges (or how easy is for them to get Admin privileges if there isn't a decent antivirus).
For what each and every critter of the rootkit category does, you can google "linux rootkits" and you'll find security blogs and reports made by actual experts that talk more in depth for each. Google up "botnet" to see some practical uses a pro has for this "taking control" of your PC. Just trashing other people's PC is a sign of a kiddy.
Then, prompts also make sure that you know that a specific program/command is operating on system files or doing something serious, so if something else breaks shortly after you can track down the responsible more easily.
If you look at sudo's manual by writing
- Code: Select all
you also see that it is supposed to log all its users and/or commands given, which is useful for forensic uses to find out when stuff happened, and can be set up to instant-notify any failed attempt to login to someone (usually the system admin).
What are the reasons for having sudo timeout specifically?
Convenience. You can leave the terminal window open for days (showing other stuff and output) and it won't be a security risk. I personally use guake a lot (drop down terminal I call with a hotkey, totally recommended), and not having to close the terminal or give another command to end the sudo session is convenient.
Please note that the timeout is "timeout between commands". If you send another
- Code: Select all
before the timer of 10 minutes or whatever expires, it is reset and starts counting down again from 10 minutes or whatever.
How much times you are looking at a terminal panel for more than 10 minutes while not doing anything?
Btw, whatever was granted access by sudo or gksudo retains root access until the program has terminated the current job
, so if you were using Synaptic to pull down 5 gb of packages from the repos it will not ask passwords again even if it will very likely not take 10 minutes to do that.
why not just password protect the screen when leaving the system unattended
I'm throwing around some security jargon I barely understand to show off how cool I am...
much lower attack surface (=code that can contain bugs that can be exploited)
Lock screens in modern distros use rather large libraries and code just to look cooler, modern, and integrate with desktop looks. This makes them much more prone to having bugs that can be exploited while a simple sudo is tiny and is therefore MUCH easier to keep bug-free.
There have been been bugs in some screen lockers in the past that allowed an attacker to crash them with a combination of keys and mouse input. I know first-hand of screen lockers that crash on their own or when interacting with something else.
While this is admittedly a bit weird and not really commonplace, note that an attacker can use a device like say an android phone with an OTG USB port disguising like a keyboard/mouse that can send thousands of keypresses/inputs per second without a sweat (like say this http://www.tomshardware.com/news/phone- ... 12056.html
), or do whatever else like spamming bluetooth requests or whatever, and if this causes the screen locker to crash, the attacker has access to the system.
Crashing sudo and granting full root access? Much much much harder. If not impossible at all.
Which is why there is no way in hell that anyone doing something serious trusts a lockscreen to keep safe the system from a real attack.
why should any networked computer allow a signal from the outside world to make changes to the system just because root is enabled?
Because it does use programs that talk with this outside world. Bugs in these programs are the issue. All vulnerabilities work like that regardless of OS, an attacker (actually a bot, an automated program made by the actual bad guy so he can go and relax) fakes a communication directed to a program or system component and exploiting the bug he can then make the PC run a script or malware that has then full root access and does whatever this guy needs(=full system access).
If the root access is restricted to a terminal or a specific program, the bug in other non-root-access programs can be used to actually inject the malware, but the critter will then fail to get root access as sudo slams the door on its face, and sit there harmlessly until the next disk format (or until a system admin comes checking who was that unauthorized user that failed to get root access).
This is especially true for Windows because it has a ridiculously huge attack surface because Net framework and their proprietary crap. Lately there was a funny vulnerability in Internet Explorer allowing a bad guy to do just that. Inject stuff and take FULL control of the system on any version of Internet Explorer. Scary stuff man, scary stuff. They also pushed the patch on XP even if it is technically not supported anymore, just to show how much they were worried by it lol.
an attacker man-in-the-middles my system update
All packages in a repository of any modern linux distro are signed (encrypted) with a key that ensures the package is read-only (can be extracted but not tampered with). If the key in the downloaded package does not match a proper key it will be auto-dumped as corrupted by the package-handling program (with or without telling you of the issue).
Even PPAs have their own key. Non-official repositories or PPAs can of course contain whatever malicious stuff they want, but the key ensures that the package isn't modified by third parties while en-route.
Check the Software Sources program to see the repos and the (pubblic part of) the key.
If you want to see more of this stuff in action add a random PPA with command line and see what is the output. http://www.webupd8.org/2012/02/how-to-u ... emove.html
Android does this thing too, and being a younger system it still had some vulnerabilities in this sign-checking systems, fixed as of version 4.1 or higher (and in most custom ROMs at 2.3 and 4.0 where the dev isn't a moron).
Then again, it's not 100% safe, nothing is. But it's a so huge pain in the backside to sidestep (if possible at all... they need to analyze stuff to find bugs they can exploit, hacking it's not magic and it costs a lot of resources to do so) that none will really try to pull it off on you. Unless you pissed off a large group of wealthy people that is.
replace an application or modify a launcher to open a fake password / password-skimming window.
This remains an issue for packages not coming from official repos (that are compiled from source by the distro mantainers, so if there is bull*** like this they will catch it), or not coming from a place/dev(s) with a good reputation. (technically speaking, all open-source stuff has the source... well.. open, so anyone with some skill can go and read it, and if they find stuff like this his reputation gets a pretty large blow as all blogs and sites caring about it start echoing the news)
Yeah, but a linux junkie needs the functionality of root access.
That's why most geeks run a rooted phone or install custom (again rooted) ROMS.
Unless your device is a knock-off (and quite a few times even when it is) rooting is usually doable. Then you use an app that does permission management (prompts you to ask if app X can get root access and remembers choice of apps that should get it without asking (like say the Apps that control governors and frequencies, or set kernel/system parameters for better user experience).
Which is what does sudo here in a PC.
If I lock out root access 10 minutes after having used it, then why was I safe during those 10 minutes but not after?
You were not safe (from threats exploiting the specific program you granted root access to). It's a good idea to minimize the time you are unsafe isn't it?
Injecting malware and taking control of a PC is basically istantaneous. If it happens during the time the bugged program used as a trojan horse has root access your system is compromised, if it happens at a time when the program has no root access it fails miserably.
So yeah, by expanding on your example, it's the difference between not locking the door while you talk at a neighbor on the other side of the street and leaving the door ALWAYS unlocked 24/7. If there was a skillful thief around you would probably be screwed anyway, but you are restricting the chances of that happening just because the skillful thief must show up AT A VERY SPECIFIC MOMENT and not whenever the heck he wants.
How exactly did we come up with 10 minutes as a default?
Dunno, never really was an issue for me anyway, although I rarely need to run as root for extended periods of time.
If I'm worried about someone brute-forcing root
No offense, but brute-force is the crappiest method evar, if you can get in a system by brute force password cracking then it's probably not even worth the time. Even with a crappy and retarded password encryption system like in Windows you can't get past 6 letter passwords by brute force.
All password-cracking systems I know use clever exploits of crappy implementations in the password system, like say the stuff based on rainbow tables that can rape any windows password with letters and numbers up to 15-16 char length within 10 minutes or so using the very same PC booted from a USB drive with the tool (with non-encrypted hard drives of course, but I have not seen a whole lot of people outside of large companies encrypt the hard drives...).
Why don't we have any such protection if enabling root is such a hazard?
As said above, bugs. Hacking is basically finding ways to exploit bugs to do things the program/device was not supposed to do.
Bug testing is a very lengthy and thus VERY expensive process if someone has to pay the programmers doing it, because you are trying to find human mistakes that are not dumb typos any decent spell-checker can detect but code written with a wrong reasoning (not apparent at the time it was written) for various reasons (missing a check on some operations, writing temporary files in a specific location that becomes unsafe, whatever).
Then fixing the mess requires much more than adding punctuation.
Debian Stable is VERY STABLE, but is also quite outdated (security and stability patches added on newer stuff are ported on older stuff that thus does not add more bugs). The same goes for devices made for critical applications (military usually), they can stay 5 or more years debugging the same firmware running an appliance doing stuff (like say an onboard flight computer) and still not catch something that has to be patched on the live devices when in the field.
But if something already got on the system to take advantage of root, then there must have been a security failure elsewhere that needs to be addressed and remedied. This should be a separate issue from enabling root, right?
Well, it's yours the system that gets compromised. Shaking a stick at the dev that made buggy software is not useful, all linux stuff waives any and all responsibility over anything. (commercial licenses of Windows are remarkably close to that, even if they fudge more with words to make you think it's more covering than it really is)
This is my machine; I fully own, access, and control its totality without exception; I rest assured all its functions are safe to use beyond the reasonable doubts of the developers and core users, and I enjoy system protection features that warn me before any action performed as root may cause system breakage.
You want the cake and eating it too. You can only have one or the other, or a compromise in between.
When even the code to make a decent menu like Cinnamon's or WIsker Menu in XFCE is so damn huge, nevermind looking at any program that is doing something serious like a media player or even the linux kernel, there is no real way of predicting if some actions will cause system breakage nor finding out all bugs on all possible systems and hardware/software combinations before a program goes live. You would need a badass AI program that can outsmart the developers of the programs it is overseeing. We are not anywhere near there yet.
So yeah, the prompts and timeouts on root are because entrusting the machine to take decisions on anything not really basic (what means allowing all programs to run as root) is generally not a good idea unless it is running a read-only firmware (and even then...).
They exist to actually empower the user and move the responsibility of most stuff the machine does on his own shoulders, even if annoying. Because if stuff goes wrong who's the guy that cleans up the mess? The PC? Nope.
Not even Windows can even remotely claim to be able to do that. Mac is technically worse in this respect but given the average userbase it has far less chances of going fubar.
It's you, the user (or a tech support guy he pays).
A computer system should be designed to meet the same expectations of ownership confidence that we have of any consumer good.
Confidence that is always misplaced badly because 99% of the appliances are cheap crap full of bugs that can be exploited.
But a serious example is how DRM ( digital rights management ) can be built-in to an isolated region of an ARM processor so that you don't really own or control your computer, the data in it, or what it does with it.
That's what open-source is for. Hardware does not run on its own, and with an open source you can go and remove the drivers running the DRM device, or for the very least make the device ignore its screams and isolate it from network, effectively neutralizing the threat.
An obvious example is how they employed the retarded limitation on a DVD's localization so that devices outside of a zone cannot play it just because DRM. Any self-respecting PC can run programs that sidestep or outright don't care of this limitation even if technically in the DVD drive's own firmware.
And please note, this is not because I'm pro piracy, but because making ransomware is not the best ethical choice to be payed for your hard work.
why there isn't at least a system integrity protocol that checks key files upon boot and restores any ones detected as corrupt to their original state ( with the user's permission, of course )?
Even a simple MD5 check would take 5 minutes or so, and given the complexity of the systems involved, compounded by the fact that each and every distro (and true linux user) does its own customizations it would become more a pita to mantain than anything else.
Windows does have a similar feature (kinda) called by the terminal command "sfc/ scannow" that can be asked to check system files and restore them if needed (takes half an hour on a decent machine), but if I have to say how useful doing that was most times... meh.
Unless there is some reason, restoring a backup or a system image you made with whatever is the safest and fastest way.
I have on occasion broke my system to the point of requiring re-installation, due to improperly using root access, and no such system integrity checker ever kicked in to save the day.
No offence intended, but this approach reeks a lot of Windows. Linux is not a closed box. You can usually fix most of these "oh crap it does not boot anymore" situations on your own (by reading some documentation from the internet and tweaking some files) if you have another bootable drive to boot from and go rescue the dead one from a full environment, even a usb flash drive or hard drive is fine, or using a live-cd (possibly from a USB drive cuz it is a lot faster).
Same applies to Android. Most devices from reputable manufacturers have a recovery partition containing a tiny OS you can use to do some troubleshooting on its own (backup and restore) or just connect to a PC and move/modify stuff with terminal commands to fix the issues you just caused in the last half our of tinkering.
I do backups of system folder with programs like rsnapshot
(after the first backup it actually saves only files that changed, everything else is a hard link to the same file in the first backup, this saves boatloads of space for incremental backups, same mechanic is implemented in the incremental backups of the ROM of my Android phone for that matter) and keep a USB drive with a fully functional Mint install or even a clone of your system partition you can boot from in case of problems to then go and fix stuff manually by restoring the most recent files from the backups. I've yet to find a good reason to not have a system partition with a 25-30 GB size.
Heck you can ask it to do a full filesystem check every boot (it is usually set to be running every 30 or so boots) and with a so small system partition it will take 5 seconds, then if it finds an issue it prompts you to ask directions and you can ask it to go and fix the issues (pretty fast again) or not.
I mean, if you swap the system files you changed recently before disaster with ones from a backup the system will be back like that day. And maybe you can look at them, look up some documentation that isn't total sorcery like the guides for Windows so you can learn how the system works, even if at a somewhat rudimentary level like me because you are not a badass coder.
This allows you better understanding of the device and of the system, and enhances the sense of "I OWN YOU", at least for me.
Now, while someone can complain and say "why the PC can't do this on its own? Windows has the System Restore functionality that does more or less the same".
It's part of the standard linux approach, admittedly more apparent in distros like Arch or Gentoo where even forums users tend to push away newbies, but it is still there for most others too.
If you want to REALLY own your device, you need to know the heck it is doing. To know the heck it is doing at any given time you need to learn and configure your set of mission-critical programs and the relevant system files for them yourself, not click on pretty buttons. As simple as that. It's not horribly hard as in most cases is just installing a couple packages and writing a few lines in a couple rather talkative text files to add settings. Then you can easily automate everything with scripts and auto-starting stuff at conditions you set, so you never ever have to touch it again.
One-click solutions don't give the user power over the machine, only the impression
of it. Because the user is just clicking a pretty button. Power is not clicking pretty buttons, it is knowing the heck is going on. So you can go and have better chances of fixing it on your own if an update to something else breaks it without waiting for a dev somewhere else to try to understand what went wrong in a handful of PCs and finding the time to fix stuff in his code for a tiny userbase, or tweak it to your exact right requirements (it's amazing how much can be tweaked and automated).
For customers that want appliance-like stuff (average mac user and people that want stuff to "just work", rather common users if I might say), Android is the way to go. System stuff is walled off and all applications installable by user are COMPLETELY self-contained or relying on system stuff that can't be changed.
Android has its weaknesses, but was designed from the ground up to cater that specific userbase.
But it's still linux, so if you are an advanced user you can do the same stuff you do with a linux PC, relatively speaking of course. (terminal and text commands to work with system for the more hardcore, scripts to automate things and tweak dynamically system settings on boot for the less hardcore)
At any rate, all this to inquire: 1) I don't see the point in sudo timeouts; can't we do better?
Well, linux (or Unix systems like BSD, but they have their own sudo too lol) is the OS running the overwhelming majority of web servers around, plus the totality of real network infrastructure (inside routers, modems and appliances, albeit it's a rather cut-down system as it has to fit in less than 50 mb of system drive), where security is an obvious high priority for everyone (excluding cheap home router manufacturers). It's safe to assume that if they did not come up with a better way for all these years it's not easy to come up with something better.
I would still like to be able to resolve the problem of sudoers ignoring 'timestamp_timeout=60'.
I told above that you still need to write sudo or the terminal line is not executed as root. In the first post you don't write sudo again and the command fails. This is normal and intended.
The timeout is for the password check. You must still write
- Code: Select all
for everything you need to be executed as root.
If you want to run a terminal as root and forget about sudo until you close it, I already linked the forum where they talk about it, and the answers for adding programs to the sudoers list so they are always run as root regardless of anything.