Michael Robertson Says Root is Safe 1174
Kez writes "HEXUS.net caught up with Michael Robertson, CEO of Linspire, at the UK launch of Linspire 5. Their interview with Mr. Robertson covers everything from hardware support to software patents, but a comment from Mr. Robertson on using root is perhaps the most interesting: "I defy anybody to tell me why is it more secure to not run as root. Nobody really has a good answer. They say 'oh, yeah, it is!', but it really isn't." I would imagine a few Slashdotters would dispute that."
Re:Uhhh (Score:3, Informative)
Perfect Example (Score:2, Informative)
Linspire, Linux dumbed down for dummies by dummies.
IRC (Score:2, Informative)
I have to say I love the OSX solution (Score:5, Informative)
The method:
By default you don't use root (although it does exist)
By default a user may or may not be an "admin" user. An admin user may perform root-like operations by authenticating again, but they give their own same password to the OS to do things.
It still knows you're you, you're just super-you. So default files are created with you as owner, for instance. This is safer because it reduces slightly the number of escalations necessary.
The effects:
The actual user password being compromised is not the reason you need a separate root account, so they removed your need for two passwords.
Bad apps still need separate priv escalation to do any harm, even if you're running as admin.
BUT you don't have to logout of your GUI session to have one app - or even ONE PART of one app - run with escalated privledges, if you authorize it to.
This means you have NO REASON to ever run unnecessary apps as an admin. No downloading just that one file as root because you're in the middle of doing a rooty thing and forgot one.
The similar linux hack:
I know you can setup similar things with sudo and a little tweaking. But this is how every OSX box ships, and it ought to be how every GUI consumer linux box ships too.
Re:My Experience with Linspire (Score:1, Informative)
http://www.zone-h.com/en/forum/thread/forum=3/t
Re:Okay now... (Score:5, Informative)
rm -Rf / as nonroot will make you give a sigh of relief. As root will be your nightmare.
I dare you to try this. Dare.
Note: you may wish to back your home directory up first. Preferably somewhere not under /, or using with someone else's permissions.
Robertson is the "Billy Mays" of the Linux world (Score:4, Informative)
Just read his responses....[a few of my repiles]
hardware damage IS possible (Score:2, Informative)
If you can write to BIOS or other boot-control data, you can potentially leave the hardware unbootable. Technically it's not hurting the hardware but you've still got a boat-anchor until it gets serviced.
Older monitors could be fried if set to a "bad state" and left there too long. Ironically, in X-Windows, you don't have to be root to change the video settings to such a "bad state."
Re:Okay now... (Score:5, Informative)
Have you looked into selinux? I don't know if it allows port 80 access from an initially non root user, but it allows you to run a locked-down root process. Problem is that it's apparently very complicated so only supports a scant few products out of the box. But web serving is one of them.
Re:Excellent commentary... (Score:5, Informative)
Ask these guys [www.iol.ie].
BTW, you REALLY don't understand what ActiveX is. Heh. Non-MS products can open ActiveX plugins.
Re:Okay now... (Score:4, Informative)
OK, ok... it isn't as bad as it sounds. It was *LATE* at night and I was sleepy. I was doing a little housekeeping (it was my first Linux installation ever) and I went into /
Another story...
Turns out that the test user had / as the home directory and the remove user script in ultrix just happily blew away the whole disk. [kenthamilton.net]
More on Google [google.com]
If you want the technical answer..... (Score:1, Informative)
1) Only root can forge packets. I have to get root to steal IP addresses and adjust routing tables most of the time.
2) Only root can install kernel modules. Kernel modules are a great way to hide from prying eyes.
3) Root can debug any process. If I can debug another process, my program can spread to that process giving me complete control of it.
4) Getting root is noisy. If actually wants that box and not just to use it as a relay of some sort, he generally will need root to take the credit card numbers, corporate bid info, etc. Local exploits are among the noisiest and are the most likely to get caught by a good syscall IDS.
5) Only root has access to most of the log files. If I'm not perfect when I take over a box, I've got to adjust the logs. I have to be root in most cases.
6) Only root has raw disk access. If I want to hide all my stuff, the best way is to directly modify the filesystem. You need raw disk access for that.
etc, etc, etc
Re:Okay now... (Score:2, Informative)
Normally, however, you would not be using it for anything - there's no point, not much that can do an admin can't.
Re:Okay now... (Score:2, Informative)
Unless he had directories which ended in '.tar', of course...
Re:I have to say I love the OSX solution (Score:4, Informative)
I think that anyone who is considering buying a PC for Lindows would be much better served buying a Mac or Mac Mini and using OS X instead. They'll spend the same amount of money and have an OS that is better-designed and is backed by a corporation and a CEO who actually know what they are talking about.
Re:Okay now... (Score:3, Informative)
Or you could run the process non-root and setup iptables rules to redirect port 80 requests to a port a non-root user can open. I think one can also set rules so that iptables only allows certain incoming ports to certain user accounts, so that no one else can run their own apache and take over the port, although I am not 100% sure on this.
Re:I have to say I love the OSX solution (Score:2, Informative)
Re:Before somebody picks on a point (Score:2, Informative)
Observe, The KDE solution:
K --> Run Command --> kdesu program_name
The Gnome Solution (I Think):
Gnome Foot --> Run --> gksu program_name
Also, you can set program shortcuts in either the K/Gnome/XFCE/icewm/wtf wm you desire/ menus to start off with the gksu or kdesu to launch an app as root.
Also, if you have a lax sudo set up, a "sudo app_name" works as well.
Least-Privileged User Accounts on Windows (Score:2, Informative)
My reaction? It's about time! This will help far more than any "Trusted Computing" initiative will.
Now before I continue, I'll comment that my workstation/gamestation is a Windows XP SP2 machine. My web services machine is a Debian Linux machine.
I have two accounts on my XP machine: One Administrator and one Limited User. I use the Limited User Account on a day to day basis for my classwork, Applications, and Games. I use the Administrator account to install new programs and program updates.
The biggest problem with a LUA policy on a Windows system is... Application manufacturers. Programs tend to be written with the impression that the program directory and HKEY_LOCAL_MACHINE part of the registry is always writable. Unfortunately, this is undoubtably because Windows 9x didn't have the concept of file or registry permissions.
On XP, by default, Limited Users can only write to their Profile directory on C:, and can only write to the HKEY_CURRENT_USER part of the registry. These are where user specific files and settings belong! The %USERPROFILE% and %APPDATA% environment variables are even set up for them! There's even an %OS% environment variable that tells the installer that this is a Windows NT system (It's set to Windows_NT).
The most recent offender for ignoring these restrictions, that I've installed, is World of Warcraft. Since it was written in 2004, its installer is aware of accounts and account types, and gave me an error that I needed to install it as an Administrator. That's all well and good, but it still tries to write files to %ProgramFiles%\World of Warcraft\WTF\Account\[USERNAME]\ heirarchy every time it runs. While the game seems to work even if it can't write its files, you also can't save any settings changes.
Re:Okay now... (Score:4, Informative)
Re:Okay now... (Score:5, Informative)
Yes. That's a good thing, for the reasons described in the parent post. It bears repeating that he did NOT say to set
An "ls -l --recursive
An "ls -l
Re:Mr. Lindows is just stirring shit as usual... (Score:4, Informative)
If this Michael guy has ever seen a rooted Linux system with one of those groovy kernel modules loaded to hide the doings of the people that rooted the box, then he would guess a 2nd time about his assertion that its OK to run Linux as root all the time.
You think that WIndows zombie boxes are a problem? However, those systems are able to be fixed (to my knowledge, don't use windows). A rooted box with a kernel module installed to hide itself, has to be completely restored.
I'm glad you mentioned OS X. I believe that it is a beautiful compromise between running as a user and asking for permission to escalate the privileges when needed. The best part of it is that it _rarely_ asks for administrator privilege, and when it does it makes sense. If someone opened an email attachment and it asked for administrator privileges, that would be a bit fishy (although some people would fall for it).
Re:Excellent commentary... (Score:2, Informative)
That's not at all true. ActiveX is just COM/OLE, which is older than Java. The origins of COM/OLE go back to the 1980s, and OLE 1 was publicly distributed with MS Office in 1991. OLE 1 wasn't based on COM, however, so is to some extent irrelevant. The first release of COM-based OLE (called OLE 2) came in 1993, at a time when Microsoft were still ignoring the Internet, with OLE controls (now called ActiveX controls) added to Visual Basic in 1994.
The first release of Java only came in 1996, and whilst it almost certainly did inspire Microsoft's rebranding of COM as ActiveX, the ActiveX technology itself was not in any way an answer to Java (and obviously couldn't have been, since it's older).
Re:Okay now... (Mod parent down?) (Score:4, Informative)
replace "executable" with "readable"
chmod a-r
Re:None of you /.ers listen/read... (Score:3, Informative)
In Linux, run as a user. A malicious script destroys your files and "toasts" your system, the only thing you've lost is your user account. As root, you can then destroy the user and user's files, and recreate the user. You've lost maybe 5 minutes of your time, and don't have to reinstall/recompile/reupdate your system.
If you're running as root, however, the script can access the *entire* system. If it runs amok, you're completely lost, and are out several hours of reformatting, reinstalling, recompiling, and reupdating the system.
This is especially important if you're running a multi-user system. When there's 3 people using the computer, if one of them gets a malicious script and runs it as root, then the entire system is pooped, and all 3 users are out of luck. When they're running as users, they can't touch each others' files, and as such, they can't screw each other over.
Re:Okay now... (Score:3, Informative)
That's why they are so prone to viruses, becoming spam zombies, etc.
A properly admined box wouldn't have that issue, but then half the coporate machines I've used haven't been properly admined let alone the home ones.
The only OS I know of besides Unix that enforces proper user/admin separation by default is OSX (it does it really nicely in fact).
Re:Okay now... (Score:3, Informative)
That should be non-READABLE (Score:5, Informative)
Re:Okay now... (Score:3, Informative)
This isn't a problem with CLIs. The GUI analogy is the Windows pop-up that asks you if you're sure you want to delete a file. Raise your hand if you use Windows and you've gotten into the habit of smaking your enter-key, sometimes before that dialog even displays.
The problem is that people want to do things quickly, so you've got people training themselves to use -f because they're in the habit of recursivily deleteing files on a regular basis and they don't feel like interupting the flow responding to a prompt. This works really well until they don't mean to do it. The Windows recycling bin is not a bad solution to this problem; there is no widely adopted *NIX equivalent.
Re:Okay now... (Score:4, Informative)
----------------
owner
This module attempts to match various characteristics of the packet creator, for locally-generated packets. It is only valid in the OUTPUT chain, and even this some packets (such as ICMP ping responses) may have no owner, and hence never match.
--uid-owner userid
Matches if the packet was created by a process with the given effective user id.
--gid-owner groupid
Matches if the packet was created by a process with the given effective group id.
--pid-owner processid
Matches if the packet was created by a process with the given process id.
--sid-owner sessionid
Matches if the packet was created by a process in the given session group.
------
You can filter network traffic based off of the same system that you can use to filter access to files. Even more fun is the ability to filter network traffic based off of a process id.
Re:Excellent commentary... (Score:5, Informative)
It's been stated repeatedly that Mozilla.org products will never implement ActiveX out of the box... ever...
There are extensions, if there weren't you could develop them, it's up to you to implement ActiveX in moz/fox and degrade your security, but THAT won't come from the foundation.
Try again.
Re:Okay now... (Score:2, Informative)
a. you attempt to delete a write-protected file
b. you use the -i switch, which some distros automatically stick into the global bashrc