Why I don't like running as root (in Puppy)

For discussions about security.
Message
Author
User avatar
SirDuncan
Posts: 829
Joined: Sat 09 Dec 2006, 20:35
Location: Ohio, USA
Contact:

#101 Post by SirDuncan »

jglen490 wrote:That's true. However, the simple act of you acting in a root account opens up your entire system to an attack. Once in, changing the mode on any file from read only is a relatively trivial exercise.
Root doesn't need to change the file permissions. As root, you can just delete everything regardless of permissions. On a *nix system, root is omnipotent.

Still, as I pointed out, it is also trivial for a non-root user to gain root power with sudo. If Puppy ever goes multi-user, I hope that Barry will exclude that command.

However, I think what Kirk and others have referred to is that the CD is read-only and not even root can delete its contents. Many people run from the CD in some way (multi-session, save file on the HD or flash drive), so they have no worries about their system files.

Even if you are running with a HD install, you don't have to worry about it unless you did a full HD install. On a frugal install, if the baddies delete your system files its not a big deal. You just have to restore 4 files and maybe GRUB. This takes a few minutes. Then restore the backup of your save file (you are making backups, right?). You may have lost some data, but you probably didn't lose too much if you make frequent backups.

A full HD install is a bit trickier. Backups are more difficult, and the file system is spread across hundreds of files. you've lost all of the ease in system restoration and not gained any security.
jglen490 wrote:It has everything to do with strong passwords
Exactly. Regardless of whether you run as root or as jimmybob16, the most important protection is a strong password.

Kirk posted while I was writing this. Kirk, you are correct that the files inside of the squashfile cannot be individually tampered with, but you can delete the whole squashfile if you are not running from CD.
Be brave that God may help thee, speak the truth even if it leads to death, and safeguard the helpless. - A knight's oath

jglen490
Posts: 9
Joined: Sun 09 Mar 2008, 18:25

#102 Post by jglen490 »

Part of the alleged "fun" of hacking into someone's system is not complete destruction, but rather control in such a way that a) the owner of the system is unaware and b) the the controller can use the one platform to gain control of more platforms.

Never say never. If something can be originally written to a squashfs, it can be re-written. It's technology, not magic. I wouldn't be as concerned about what is on the CD, as you say if files are on a CD-R, not even root can alter them. Once they are in memory, that's another story, plus Puppy can write certain files to disk for permanent use even in a frugal install or a memory only install. So be careful what you download and what you save/keep, and monitor what ends up as saved

Again, I have no ill-will towards the concept of Puppy Linux, the creator of Puppy Linux, or any Puppy Linux user. The myth of infallibility, is just that - a myth. The risk may be different in some use cases, but that's all.

Applying good security practices including strong password usage (with or without the use of sudo), will serve you better than anything else, including reliance on the good will of others when you are on-line.

kirk
Posts: 1553
Joined: Fri 11 Nov 2005, 19:04
Location: florida

#103 Post by kirk »

I don't think it's reasonable to add the extra aggravation to run as a non-root user because your system may be compromised by some inconceivable attack. Especially since Puppy is so absurdly easy to fix. If I applied the same logic to the rest of my life I'd have to live in a bio-bubble inside a bomb shelter.

Again, unless you install malicious software, you won't have a problem. People who install malicious software, do so thinking it's safe. So if they run a multi-user system and the software package says you must be root to install, the user will su to root to install it. The myth that a multi-user installation protects you from mal-ware is just that - a myth. Unless you don't know the root password. Multi-user systems are great when you actually have multiple people using it.

So far the reasons I've saw for running as non-root are:

* It gives me protection from the unknown for unknown reasons.
* It makes the hapless type sudo before screwing up there system

Edit: Just read Pizza's post on the previous page, totally agree and I have to add one more reason to my list:

* Avoiding becoming a zombi :lol: :lol:

I guess I'm done with this thread.

User avatar
nipper
Posts: 150
Joined: Sat 22 Mar 2008, 16:08

#104 Post by nipper »

My next door neighbours do not lock the front door of their house when they leave, either for the day or for a two week vacation.

They can't think of a reason to lock it. Does it follow logically that there is no valid reason?

In over 10 years they have not had anything stolen. Does if follow logically from that that they never will?

User avatar
8Geee
Posts: 2181
Joined: Mon 12 May 2008, 11:29
Location: N.E. USA

#105 Post by 8Geee »

Sir Duncan:
If by that you mean "can you change the root user name or password?", the answer is, yes you can change the password. I don't know if you can change the user name. It would be a good idea, though. Changing the name may cause some problems with scripts and such, but it is good security practice.
That will cause me to edit my former post, and render Puppy and derivitives as most acceptible. Being the ex-Win user, I can toss the old desktop into the recycler. I knew someone got the root secured, it certainly isn't the default OS in the Eee.

Many thanks

oblivious
Posts: 303
Joined: Sat 14 Apr 2007, 05:59
Location: Western Australia

#106 Post by oblivious »

nipper, I think your analogy with household security is a good one. The way I see it is this - you should lock your house, you should insure its contents, you should have security screens/window locks, have someone collect your mail if you go away, etc. And if all you have is a black&white tv on a milkcrate, perhaps not even that....

But you do not need 24-hour patrols by armed guards with dogs, a set of monitored security cameras, direct panic button access to the cops, etc. I consider much of the security measures promoted in linux are analogous to the security measures needed for a vital commercial service, not for a home computer with dog photos and recipes. I would find it annoying having to enter a 16-digit security code and call into base to get into my house and some of the security measures are similarly annoying to me.
Part of the alleged "fun" of hacking into someone's system is not complete destruction, but rather control in such a way that a) the owner of the system is unaware and b) the the controller can use the one platform to gain control of more platforms.
Yes, they could make your computer a zombie. How is hiding "zombieness" achieved? How can such access be hidden? If you get made a zombie, can't you see that your processor is working away, sending stuff? Or your modem flashing away? How is it hidden?

There are different aspects to security and they are all bundled up and discussed as if they are one thing. For example - In a business, your system files are important, even a day without the system can be a nightmare - so you need to keep users away from them so they can't crash the system. Root/user is essential. It may also be essential where you've got dopey kids on a home system. But it may not matter at all when you've got a single user home computer with an easily reinstalled system.

Data files - protection in a business is essential. Loss/corruption catastrophic. Home system - it depends what you've got on the computer. Root/user and file access permissions are more important for important data.

Hacker/zombie issues - these should be of concern for all systems, but how does root/user come into it? Can a hacker do nothing from a user account? How are processes hidden? How does a hacker get into a system connected by a router which is "fully stealthed"? What happens next? If a user downloads a file with something "dodgy" in it, how is the system compromised (if at all?) Is it only of concern if a root user downloads a dodgy file? How do you detect dodgy files?

There are different aspects and I don't find the "you must never run as root!" admonitions particularly useful in understanding exactly what's being talked about and what the specific risk avoided is in each case.

User avatar
Pizzasgood
Posts: 6183
Joined: Wed 04 May 2005, 20:28
Location: Knoxville, TN, USA

#107 Post by Pizzasgood »

A limited user can be almost as good of a zombie as the root user. Not being root would be a slight inconvenience, but for most systems it wouldn't be a show stopper. To stop this, you would have to severely limit the limited user. Probably the best would be if there's a way to prevent a limited user from making his own files executable and to prevent him from preserving the executable bit of an extracted file. I don't know if there's an easy way to do that. I think partitions can be mounted with a "noexec" flag that prevents anything on them from being executable, so if you confine the user to such a partition and ensure that they have no write permissions on any other partition, then I think that would be pretty secure (assuming there are no holes letting the user increase his permissions). The user would be unable to download and run any code. That would make the biggest remaining holes the root password and any buggy apps. Or if the user was a complete dunce and copy-pastes an entire program into the console.



If you were a really good hacker, you could replace the network and CPU monitoring tools with tweaked versions that would not show your processes or CPU cycles. Then if you carefully craft your code to not run the processor very hard and to only send data when other data is being sent also, you could make it much harder for an unsuspecting victim to notice you. I don't know how practical this would be, but AFAIK it's entirely possible.
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]

User avatar
nipper
Posts: 150
Joined: Sat 22 Mar 2008, 16:08

#108 Post by nipper »

Pizzasgood wrote:A limited user can be almost as good of a zombie as the root user.
Consider that one more time, slowly. In the "big" distros "limited" means limited, a limited zombie doesn't have necessary permissions to run a mail relay (to distribute spam, etc) or to change system configuration files or a lot of the important binaries. A limited zombie would be, well, limited and thus less of a threat to any but the users own files.
Pizzasgood wrote:Not being root would be a slight inconvenience, but for most systems it wouldn't be a show stopper. To stop this, you would have to severely limit the limited user.
*Most* systems, or only those which give the normal user admin rights? Until the *buntus, etc showed up a "severely" (your term) limited user was the norm, it still is except for the so called newbie-friendly distros.
Pizzasgood wrote:Probably the best would be if there's a way to prevent a limited user from making his own files executable and to prevent him from preserving the executable bit of an extracted file. I don't know if there's an easy way to do that. I think partitions can be mounted with a "noexec" flag that prevents anything on them from being executable, so if you confine the user to such a partition and ensure that they have no write permissions on any other partition, then I think that would be pretty secure (assuming there are no holes letting the user increase his permissions).
What you are describing can be done for individual files and directories, no matter which partition they are on and in the secure multiuser-distros the only place the user can write is in their own home directory. You have the concept absolutely correct.
Pizzasgood wrote:If you were a really good hacker, you could replace the network and CPU monitoring tools with tweaked versions that would not show your processes or CPU cycles. Then if you carefully craft your code to not run the processor very hard and to only send data when other data is being sent also, you could make it much harder for an unsuspecting victim to notice you. I don't know how practical this would be, but AFAIK it's entirely possible.
One doesn't even have to be that good, scripts exist that do the heavy lifting. Something you haven't mentioned, crackers also modify logging to hide their presence, sometimes just delete logs. Change the binaries for tools like rootkithunter, and chkrootkit so they show a clean run, etc.

User avatar
Pizzasgood
Posts: 6183
Joined: Wed 04 May 2005, 20:28
Location: Knoxville, TN, USA

#109 Post by Pizzasgood »

I admit I don't know a whole lot about true multi-user systems and I might be missing something. I let my mouth get ahead of my mind in that last post and started talking like I know more than I do. Sorry. For me, any user limited enough to be "safe" is too limited for my needs, so I may tend to underestimate how limited they really are. (I had no idea about sudo until recently though; I always thought it was analogous to 'su -c <cmnd>')

Does a limited user have permission to send data over the network? If so, my my thinking that user can be a zombie. Maybe it can't run a mail server, but I imagine it could still participate in a DOS attack. If it can phone home, it can also be a data collector. Another possibility is that it could try to crack into yet another machine, possibly one with less security.

Of course, I could be wrong. It could be that the user can only run a very small number of network applications, such as a browser, mail client, and wget. But even wget would let a zombie eat somebody's bandwidth.
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]

User avatar
nipper
Posts: 150
Joined: Sat 22 Mar 2008, 16:08

#110 Post by nipper »

Actually, Pizzasgood, it seems to me that you are thinking a lot about this and that can trump whatever lack of knowledge because you will ultimately increase the knowledge.

Re multi-user distros: Lots of the binaries are owned by root and can only be executed by root.

I understand what you mean about being too limited, for that case you can use the groups to which a user belongs to allow "extended" privileges for that user. i.e. being a member of the admin group.

One useful part about limited users is that, even if the userspace gets compromised, the system is still OK. Root can logon the system, eliminate that username and all associated files (they are in the user's home dir anyway) Even if it could "phone home" is could only "collect" data about that user, it can't read any other user's files (unless configured that way) nor could a user run a keylogger on another user's input.

Accounting, with a multi-user system it can be easier to know just who did what, this can be useful for training or discipline, as appropriate.

In the type of system we are currently discussing the system administrator has a great deal of freedom configuring what an individual user can do, you could even stop the user from being able to configure their own desktop if that was deemed necessary. It would be possible to restrict network access and/or anything else. However, you are correct, there is no guarantee that nothing bad can happen when people are allowed Internet access.

Since sudo is new to you, you might also want to have a look at sux.

Alan_x
Posts: 2
Joined: Sun 07 Dec 2008, 18:13

Why I don't like running as root (in Puppy)

#111 Post by Alan_x »

Interesting discussion. I've been dabbling with various flavors of linux for a few years now. Primarily, though I still use MS - not because I like it, but because I need to get stuff done and I know how to fix my Windows when it (inevitably) breaks. Also, my job is helping people with their PCs and so far, all of them are Windows PCs. When I get a new client, often due to a virus, I regularly use Puppy in the cleanup process.

One reason I'm reading this thread is because I'm looking for a windows alternative for my clients and, ultimately, myself as well. MS gets more obnoxious daily,it seems. On the other hand, I don't want to jump out of one frying pan and into another one, just warming up. Since the emerging threat these days is from the web, via the browser and/or some vulnerable plugin, like flash. If cross-platform programs are being targeted, it seems like just a matter of time before malware writers start creating cross-platform payloads to go with them. At least some of my clients are going to want a full HD install of Puppy, leaving them vulnerable.

So, here's a thought: The way I've been dealing this on windows is by using a program called Sandboxie. It's a nicely compact (350k) program for Windows that takes an approach to security that makes an end-run around the current discussion.

So, say you want to run Firefox (or any program). You either click a pre-configured icon or right-click and choose "run sandboxed". Firefox opens, but everything it tries to read or write to is intercepted by Sandboxie and first copied into a "sandbox", an isolated set of directories in the user's "Documents and settings" directory. Then Firefox is forced to use those copies for all its activities.

Then, when you browse to a malicious page, which perhaps uses Javascript or Flash to download and "install" some nasty proggy. The baddie thinks it's got you: It put itself into the system files, and everywhere it could think of in the registry. But when you're finished browsing and you shut off Firefox, the nasty vanishes, because it put itself into copies of the system, registry, etc. and when you shut off Fx, all those copies are automatically deleted. Even if you chose to keep them between sessions, they couldn't run at re-boot because they're in the wrong place.

What about your data? A sandboxed program can read files off your HD, but it can't actually write to them. Furthermore, you can restrict which files/directories it can read. So, you can set your "browsing" sandbox to block any reading of say, the directories where you store your personal docs.

True, you could go to one webpage and get a keylogger, then, in that same session, if you went to your bank, the keylogger could read your password. To prevent that, you simply create another sandbox, just for banking, or shopping. There are lots of other tweaks, too.

It seems that if this idea could be implemented in Puppy, or any linux, it would eliminate at least the internet-browsing related security issues of root, even for those with a full HD install.

What say?

User avatar
Pizzasgood
Posts: 6183
Joined: Wed 04 May 2005, 20:28
Location: Knoxville, TN, USA

#112 Post by Pizzasgood »

That's similar to running Puppy with the pfix=ram option. In that case, all the system files are "writable", except that instead of overwriting the originals, a new copy is made and used in place of the original, for the duration of the session. At the end of the session, when you reboot, you have the option to create a save file. If you do, all those copies are saved in it. If you boot from that save file, the copies are used like normal files, so they can be further modified. But if you don't create a save file, they vanish when the power is cut.

The problem is that the harddrives are still writable, in the normal sense, so if compromised, the hacker could theoretically mount the drives and write over things there. Also, what you describe is an app-by-app deal, whereas this is for the entire thing. So to get rid of nasties installed by the browser you'd have to reboot, not just close it down.



Running the browser as a limited user, separate from whatever user the user is (root in this case), would help with that. (Clarification: the user would still be root or whoever, but would run the browser in such a way that the browser is running as the user "browser".) Determining what it can and cannot read and write to would be done through the normal system of user and group permissions that Linux uses. It shouldn't be able to write to anything except that limited user's home directory. It would be able to read most files still, but you could set files to non-world-readable to change that.

Any changes it makes within the home directory would be preserved, but it would be feasible to set up an initial configuration, store it in an archive, and then just completely replace the home directory with a fresh copy each time you start a new session of the browser. In fact, if you used only the default settings of the browser, you could simply delete everything in the home directory, without replacing anything.

There are directions in the forum for running Seamonkey as another user. I haven't read them myself so I don't know how far into it they go.


Another similar topic that I only know a small bit about is the "chroot jail", which basically makes a program think that / is somewhere else, like /tmp/browser/jail/, so that when it tries to access /usr, it will actually look at /tmp/browser/jail/usr/. To have it be able to read other files you'd have to copy them into the jail.
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]

webworm98
Posts: 77
Joined: Fri 28 Apr 2006, 14:45

#113 Post by webworm98 »

Yes, I know this is an old thread. I have been doing research, now that I got a modem working in puppy frugal install. I want to do a full hard drive install of puppy but want to be able to protect it, without having to reinstall puppy if its gets infected and to protect my hard drive.

My comment, forget the user accounts or root account. What about prompting people for system changes or for certian actions that mailware or spyware will do? Would that work?

Just a thought.

User avatar
sikpuppy
Posts: 415
Joined: Sun 29 Mar 2009, 05:54

#114 Post by sikpuppy »

webworm98 wrote:Yes, I know this is an old thread. I have been doing research, now that I got a modem working in puppy frugal install. I want to do a full hard drive install of puppy but want to be able to protect it, without having to reinstall puppy if its gets infected and to protect my hard drive.

My comment, forget the user accounts or root account. What about prompting people for system changes or for certian actions that mailware or spyware will do? Would that work?

Just a thought.
Like Vista? That worked well with people. So well that it is almost a urban legend.

The web browser is the biggest threat to minion Linux users, I would imagine. Mainly because it's easy to clicky click onto compromised sites with dodgy browser software and a lack of common sense. It doesn't matter if you have the great firewall of china and 20 people monitoring your incoming packets, if you put in your password and bank details into a phishing site....you fail.

A browser that is reasonably recent, say a couple of months at most, a hardware firewall on your router and good online practices: most people won't have an issue.

Oh, and not using MacDonalds WiFi to trade stock or buy stuff online is a good idea. Unless you are Master of Philanthropy.
*
edit* and screen locking is not a bad idea, even if it's just the screensaver so your workmates/sister/flatmate can't get on your Spacebook page and upload that picture you thought had been destroyed.
ASUS A1000, 800Mhz PIII Coppermine!, 192Mb RAM, 10Gb IBM Travelstar HDD, Build date August 2001.

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#115 Post by mikeb »

Well when I'm not root I get told I cannot eject a cd using software.....it's so harsh
...like ...woah ...that's a security risk.

mike

User avatar
sikpuppy
Posts: 415
Joined: Sun 29 Mar 2009, 05:54

#116 Post by sikpuppy »

mikeb wrote:Well when I'm not root I get told I cannot eject a cd using software.....it's so harsh
...like ...woah ...that's a security risk.

mike
You need to add yourself to a user group that CAN eject CDs. Easy peasy...
ASUS A1000, 800Mhz PIII Coppermine!, 192Mb RAM, 10Gb IBM Travelstar HDD, Build date August 2001.

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#117 Post by mikeb »

You need to add yourself to a user group that CAN eject CDs. Easy peasy...
hmm tried that for audio and still no go....and seems like a non techie unfriendly way of doing things...why is it not like that by default. I guess that's why the root only route is taken to make linux appealing to the masses. A window's user account would allow cd ejection.

Ok which group can eject CD's?? oops sorry wasn't that easy peaasy for me.....I am not one of the intellectual elite I'm afraid. :D

mike

User avatar
sikpuppy
Posts: 415
Joined: Sun 29 Mar 2009, 05:54

#118 Post by sikpuppy »

mikeb wrote:...I am not one of the intellectual elite I'm afraid. :D
Me either. In fact I am stunningly dense on occasions too numerous to mention. (I won't bore you be mentioning them)

Depending on how things are set up, eject should work on Ubuntu out of the box. However, one thing i recall is after using some CD and DVD burning applications is the eject no longer works for some reason. It could be a function of the application failing to release it's lock on the drive (which prevents the disc from being ejected during burning) or it could be something more simple.

However, I have found the "eject" command works pretty much when all else fails. I even had a icon for it at one point on the desktop I could press to eject a recalcitant CD/DVD.

Code: Select all

eject -T
This toggles the tray. Since it may need admin priviliges for other distros than Puppy, use the Sudo command before it, then enter your password.

Not easy peasy I suppose, but it works.
ASUS A1000, 800Mhz PIII Coppermine!, 192Mb RAM, 10Gb IBM Travelstar HDD, Build date August 2001.

User avatar
Pizzasgood
Posts: 6183
Joined: Wed 04 May 2005, 20:28
Location: Knoxville, TN, USA

#119 Post by Pizzasgood »

mikeb wrote:Well when I'm not root I get told I cannot eject a cd using software.....it's so harsh
...like ...woah ...that's a security risk.

mike
Imagine you are running a server on campus that thousands of students can log into. They use it to run expensive programs that would otherwise cost them a lot of money. You don't want these users who may be on the other side of campus or even in another state to be ejecting the CD drive for no reason. A prankster could write a script that continuously opens and closes the drive forever (until noticed and killed by a tech) in order to wear it out or just be annoying. Not to mention ejecting it while a tech was trying to install an upgrade...

That sort of environment is where multiuser support in *nix originates. It's why some of the rules don't really make sense when you only look at them from the viewpoint of a desktop user. Linux doesn't use the "give the user free reign and revoke the few things he shouldn't touch" method - it uses the "revoke everything possible and only give back what is absolutely necessary" method. Even if some action isn't an obvious security flaw, there could be unforseen bugs that could be exploited. Assume all users are the enemy and keep them as weak as possible.

(By the way, that was not a hypothetical server - I used it last semester to run Virtuoso for my VLSI assignments, and sometimes use it for Matlab (though I do have Scilab on my own computer).)


Ejecting the CD tray is probably just a permission issue. Probably there is either a device file somewhere that would need to be adjusted to be writable by your user, or else the eject program would need the setgid bit set and be owned by a group you are a member to.

Some programs/actions simply refuse to work for a user though and need real root privileges.

My comment, forget the user accounts or root account. What about prompting people for system changes or for certian actions that mailware or spyware will do? Would that work?
And how do you propose to do that? Manually adjust every such program and library so that it pops up a dialog box? OTOH, if you went with a Puppy that had limited users, it wouldn't automatically pop up a box asking for authorization, but configuration type commands would still refuse to run.
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#120 Post by mikeb »

This toggles the tray. Since it may need admin priviliges for other distros than Puppy, use the Sudo command before it, then enter your password.
Hmm this function is buried in the kde desktop so not so easy to hack around. I will fiddle again soon.

If someone could run a script to eject a cd remotely I'm sure they could do something far more interesting/damaging...If they had that level of access (on linux) then there is a problem far more serious that cd tray control. (eg mount/unmount works as a user)...a question of confused priorities.
By the way sound suffers the same problem...damaging remote noise problems perhaps :D One is testing out multiuser on linux with security in mind and coming across some odd issues like this.

Sideways topic...any free windows lightweight on demand virus scanners to recommend? (avg was hogging 300MB, 140MB ram )?

mike

Post Reply