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.

Quote:

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.

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._________________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

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.

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._________________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

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.

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.

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._________________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

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?

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.

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.

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:

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.

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.

Quote:

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._________________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

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 One is testing out multiuser on linux with security in mind and coming across some odd issues like this.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum