Mark <mark@comparity.not.example.net>: > This is a question related to my next post. Caveat: haven't read it yet. > If there is a user with non-root access to their account, we are > dependent on their having a good password to ward off too much nasty > activity. > > I am told that it is fairly easy with user access to install a rootkit > of some sort and totally compromise the system. No. User access can affect User's acct., and that's all, assuming of course that that user doesn't have access to root owned stuff. > Now it seems to me that if this user is careless with this password, > then the whole server is at risk. How true is this? Doesn't this weaken IFF there are easily compromisable services running on the box, yes mere users can do irreparrable damage. Huh. "aptitude update && aptitude upgrade", aka, "Install updated/fixed software". Do it often. Better, don't run software you can't protect, or at least don't expose it. Firewall and proxy and ... any Windows machine. Don't run stupid services on Internet facing interfaces without considering their capabilities, good and bad. > If that is the case, what do ISPs do, with their thousands of ordinary > users? What does anybody do? Run lots of traffic monitoring software. Scrutinize output. Cross fingers. > I ask this because I have inadvertently left an account open with a !@#$ happens. Clean up. This can happen using any OS. This has nothing to do with Linux. -- Any technology distinguishable from magic is insufficiently advanced. (*) http://blinkynet.net/comp/uip5.html Linux Counter #80292 - - http://www.faqs.org/rfcs/rfc1855.html Please, don't Cc: me.

On 04 Oct 2007, in the Usenet newsgroup comp.os.linux.security, in article <4704dce6$0$26400$88260bb3@free.teranews.com>, CWO4 Dave Mann wrote: >I'm concerned about the "start from scratch" advice. I've experimented >with the concept of taking an otherwise good system -- and one where >everything is "just like I want it to be" and then reloaded the ubuntu >system from a DVD which I had just burned with the most current ISO from >the Deb site. In each case, the box lost just about all of the settings >I had made to it and to really make things a pain, I got the "$HOME is >being ignored ... change permissions to 644..." so that user settings >were NOT preserved. Well, yeah - you reinstalled the system, and things are now in the default mode. Our backups don't restore to the distribution default, but rather to the latest company approved configuration that our admins spent weeks setting up (and maybe years refining it to the current form). Then we take the customized data that may have been on this system and (after vetting it if there was a chance of compromise) restore that to bring the system back to the known good setup. Now, what the permissions in home look like (some default to 644, other to 640 - I don't know what you had, and what security nanny may be running to screw things up otherwise) what application are you running that is ignoring permissions on a restore? >This even through the entire home/user directory was dd moved from the >backup hd. Do you literally mean '/bin/dd if=/source/of/backup of=/home/user'? That's not the way I'd be doing it. >I have also copied a dd image back and forth to test a complete system >restore and found that there is ALWAYS some glitch which prevents the >system from going back to where it was, only with a clean OS. 257722 Apr 12 2006 Linux-Complete-Backup-and-Recovery-HOWTO although this subject gets lots of coverage in popular magazines. Obviously something isn't right, but I don't know enough about what you may be doing to say why. Some of the problems may be due to inappropriate tools/helpers (or let's just say stuff that isn't doing the job the way you expect it to be done). Example, changing ownership of files invariably removes S[UG]ID permissions - that's a security feature. >Sorry to carry on like this, but I have just not had good luck with full >system restores over the past 10 years of using Linux. If it is any >consolation to me, none of our shop's Windows machines (which are long >gone since we switched to only Linux) nor the two BeOS machines were any >different. There is "always" something ... "Dave, I can't let you do that..." ;-) Old guy

On Thu, 04 Oct 2007, in the Usenet newsgroup comp.os.linux.security, in article <47055a00$0$29246$ba620e4c@news.skynet.be>, goarilla wrote: >Moe Trin wrote: >> I'm amazed at the number of total fscking IDIOTS who think that >> 'chmod 777 *' is the way to fix a permission problem. Luckily, the >> really dumb ones do that recursively from / and really screw up >> access to their systems, give up, and go back to running windoze95 >> because it doesn't have these problems. > >that must be a joke right ? Unfortunately, no. Today is only the fifth and I've already seen a fscking idiot posting to another *nix newsgroup that he did a chmod -R 777 / but it didn't fix his problem, and now he can't log in. Wonder why ;-) >my default umask is 0077 btw Depends on your threat model. Who has access to the file system, and what have you got in there. The _traditional_ value that a lot of systems still use by default is 022 (recall the execute bit is never set by default on file _creation_ though it may be _copied_ if using '/bin/cp' to copy a file). >but one really does see that a lot even in howto's >hosted on so called respectable OSS sites : >eg: now we make the file executable: >chmod a+x or chmod 755 are very common in this case Where is the file, and what is it being used for? I really do expect that files in /bin/, /sbin/, /usr/bin/, /usr/sbin/, /usr/local/bin/and /usr/local/sbin/ would be 755 - or why else is the file placed in those directories? On the other hand, files in ~/bin/ are usually 700 though if others don't have any permissions to the directory, that really isn't an absolute requirement. >ok i forgot about login :D There are usually a number of files on a system that have to be S[GU]ID ranging from /bin/login, /bin/passwd on to /bin/su and possibly your mail server or mail downloading tool. find / -perm +04000 -exec ls -ld {} \; 2> /dev/null > /tmp/SUID.files find / -perm +02000 -exec ls -ld {} \; 2> /dev/null > /tmp/SGID.files >but still eg: i only allow a certain group su or sudo And the permissions on /usr/bin/newgrp? >> You did notice that what was being exploited here was an FTP server >> with a well-known username and password that was set up to allow >> uploading of files. >i was just giving a common scenario ! >jeeeeez, but still i wouldn't call that exploitation >there was no indication the FTP server was compromised >it could just be a legit account Probably is a legit account, but it's _probably_ being used for purposes that the system administrator wasn't intending. That remains an exploit. Old guy