You are not logged in.

#1 2009-04-03 15:44:54

LeoSolaris
Member
From: South Carolina
Registered: 2008-03-30
Posts: 354

"Security" for user data

Ok, I was reading through one of the many, many, many, many ....  many "Linux virus" threads and an idea struck me. In theory a virus/malware/social engineering/what ever could gain access to the userland data. In KDE and Gnome, it can add itself to the autolaunch file so it will restart with the computer. To gain root, making a bash alias to a userland script that sends the password to the needed installer/ as well as spoofing sudo/gksu/gksudo to achieve the same would still get to the underlying system.
http://www.geekzone.co.nz/foobar/6229 is where I am drawing these from.

Would this 'fix' the issue? And it is still an issue to me, because gaining root access isn't nearly as damaging to me as say... logging my keys when I access my bank account, for instance.

1. Set autostart and bashrc owner to root.
2. Set their groups to wheel (or you can make a new group for uniqueness.)
3. Set the permissions so they can be executed and read by anyone no password needed, but only writable as root.
4. (Optional if necessary to work for either one) set them up in a different location, say /etc, and symlink to them from their normal locations so they execute as the user. (Not sure if symlink is needed or actually the most effective way of doing that idea if it is necessary. I may be badly misinterpreting the use of symlink here... In fact, I'm pretty sure that I am.)

I am not sure what effects this would have on the system. I think, if it works it may autostart everything as root, and perhaps automatically make you root when you open bash. But then again, I have no idea. It might work flawlessly without altering the permissions of anything autostart spawns or the bash prompt.

Also: I'm using Openbox rather than Gnome or KDE, so I am not sure how well the .desktop or launcher workarounds would function on my system.

Once again, I have not tired this solution, so if you're a newbie, don't just blindly try this out. I am just asking to see if anyone else is as paranoid as I am, and what their opinion of this idea is.


I keep getting distracted from my webserver project...

huh? oooh...  shiny!

Offline

#2 2009-04-03 15:59:05

hatten
Arch Linux f@h Team Member
From: Sweden, Borlange
Registered: 2009-02-23
Posts: 736

Re: "Security" for user data

cli>gui
.desktop isnt hidden in the terminal

Offline

#3 2009-04-03 17:26:42

LeoSolaris
Member
From: South Carolina
Registered: 2008-03-30
Posts: 354

Re: "Security" for user data

True, but inconvenient. I've never really liked File Managers for cli. Besides, it only solves the issue for a small number of people who A) use cli intensively and B) act with caution around the file extension .desktop. This is aimed at desktop users rather than cli users, since most people connecting to the internet use Xorg and something on top of X.

I am not even sure that this sort of trojan horse will even work outside of Gnome and KDE, since they are the ones who use launchers.

Regardless of method of delivery, would shielding these two files in the manner described add to the level of security for Linux installations or just bork everything? The point of doing so is to prevent root password theft and autostart access so a reboot (and possibly a log out) will kill the process, thus only compromising userland for a limited time.

Edit: Minor bump. I am really rather curious about this. If there are any security gurus out there who know if this could work....

Last edited by LeoSolaris (2009-04-15 13:31:35)


I keep getting distracted from my webserver project...

huh? oooh...  shiny!

Offline

#4 2009-04-15 13:33:13

LeoSolaris
Member
From: South Carolina
Registered: 2008-03-30
Posts: 354

Re: "Security" for user data

Ok...  I guess I have to do a manual bump rather than an edit to a previous post.    Good to know for future bumps.


Anyways...


I keep getting distracted from my webserver project...

huh? oooh...  shiny!

Offline

Board footer

Powered by FluxBB