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

For discussions about security.
Message
Author
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

Testing1.2.3.
Posts: 2
Joined: Thu 01 Mar 2012, 02:14

Solved

#121 Post by Testing1.2.3. »

Not sure if this is only for newer distributions, but you can use

Code: Select all

su spot
This will give you user level access to start applications from the terminal...

This is an older post, but I hope that information helps someone.

I read through some of the pages hoping for a solution.

nooby
Posts: 10369
Joined: Sun 29 Jun 2008, 19:05
Location: SwedenEurope

Re: Solved

#122 Post by nooby »

Testing1.2.3. wrote:Not sure if this is only for newer distributions, but you can use

Code: Select all

su spot
This will give you user level access to start applications from the terminal...

This is an older post, but I hope that information helps someone.

I read through some of the pages hoping for a solution.

I don't like " running as root (in Puppy) " either.

(Going derail just to explain. I love that I can run as root
this easily on Puppy but I don't like the added risk of being root okay)

But how can something that simple as

su spot

be the end of many years of futile search for a solution?

Sure I would be very happy if it is the solution but that would be
a surprise? I mean the Dev of Puppy has not accepted it or
should I trust them don't know about it?

We have a thread named Fixing Fido maybe you can help out with that
one using the su fido instead?
http://murga-linux.com/puppy/viewtopic.php?t=71358
Test it and give a description of how it solved things?

Friendly smile
I use Google Search on Puppy Forum
not an ideal solution though

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

#123 Post by Pizzasgood »

Yeah, we know about spot. That lets you run things as a user on a program by program basis. Using 'su spot' is a good way to safeguard a program that might be hacked, e.g. your browser.

But no, it isn't a real solution to the actual problem caused by lack of multi-user, which is: how to securely share the OS among multiple human users. Multi-user is about protecting the other users of your install, not yourself. If there aren't any other users, then there isn't much point - even if you did run as a limited user, the hacker would have no trouble at all reading your data and setting up his code to run as soon as you log in.

The problem with being root is that IF you have other people using the computer, and the root account is compromised, the hacker can access everybody's data, and can bring down the entire OS if he wants. Giving each user his own account means they can't tamper with the OS and they can't tamper with eachother's files. If one of them gets hacked, the rest are still safe (assuming a strong root password and no other exploits leading to root). That is the functionality that multi-user provides. The 'su spot' technique isn't sufficient to provide that.
[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
cobelloy
Posts: 204
Joined: Mon 23 May 2005, 07:12
Location: Karratha W.Australia

what am I doing wrong ??

#124 Post by cobelloy »

hi, trying to run chrome - wont run as root, solutions such as the puppy-chrome script here http://murga-linux.com/puppy/viewtopic. ... 17&t=72667 and adding --user-data-dir= option to the google-chrome script will allow it to start but leave it unable to access any google features (gmail, google search etc...) another solution is to edit the binary file /opt/google/chrome/chrome so it no longer checks for superuser status - but I don't know how.

so

I added a user - with a home directory but when I su - user I get permission denied??

uuuggghhhh
please help

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

#125 Post by Pizzasgood »

My guess would be that you forgot to make the new user the owner of his home directory, which could be done like this (adjusting for your own particulars):

Code: Select all

chown -R user:user /home/user
[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]

Post Reply