Something I thought was secure but people have convinced me otherwise

ConnorBehan · 2007-09-25 03:15:17

Warning: Please read through all replies before you try this approach... There are strong suggestions from devs to not try this at home

If you're like me and the first OS you used with any regularity was windows... you might be annoyed with having to su, sudo, gksu, chown and add groups to configuration files. With windows I had an administrator account and I somehow managed to not contract a virus although I had several close calls. I was the master of my PC and I liked that.

When I first installed Ubuntu, I was ever so fed up with having to type my password if I wanted to install something , edit xorg.conf or anything outside /home or capture footage from an IEEE1394 camera for example. If I were fully comfortable with the terminal, prepending sudo to every command would be easy but it is my icons that gave me trouble. I would click on the gedit icon, open xorg.conf, then realise that it was started with insufficient permissions, have to close it, open up the terminal and type sudo gedit, or type sudo chown connor /etc/X11/xorg.conf, save, then type sudo chown root /etc/X11/xorg.conf. Kind of a waste of time if you edit these files as much as I do.

Personally I have edited root owned files THOUSANDS of times on Arch already and for my first few weeks of setting it up I used root exclusively (bad form I know but to do otherwise I'd have to be a masochist). After going back to using connor and typing my password, or redoing commands where I forgot, I came up with a new idea.

Correct me if I'm wrong but a new Linux user does not log on as root, primarily because someone so new would screw up the system somehow, not know how to correct their mistake and break their programs... but let's face it, most Arch users know what they're doing enough to not let this happen... even me. An experience user should still not log on as root because a buffer overflow, while unlikely can cause the variables of a program to have grossly wrong values and leave an insecure backdoor into one's system if the program happened to be listening on any WAN port.

Here's my solution... you can flame and disapprove of it all you want but hear me out. It only works if you own your physical computer and only you use it: Daemons startup and some of them like sshd are started by root (because you haven't logged in yet) so disable root access for ssh to keep it secure if you want to keep WAN port 22 open. I login as root and type startx. This so far does not present a security risk because I do -nolisten tcp but if you wan't to use X over a LAN, close only the WAN port that it listens to.

I then have all my icons and menus setup so that programs are only started as root if they have no possible access to a network no matter what. Firefox is gksu -u connor firefox, thunderbird is gksu - u connor thunderbird, you get the idea. Other apps that I did this for include avahi, azureus, pidgin, wireshark, dc++, xscreensaver, xscreensaver-demo and qalculate because it downloads currency exchange rates. I closed the WAN ports used by CUPS, samba, MPD and all services that I primarily want to use over a LAN.

The best part is gksu will not even ask for your password! And the application still starts with least user privleges and ps -ef proves it. I'm sure you can do the same thing with kdesu for you KDE users. I use Thunar (because I use XFCE) and it is a non-networked file browser (unless you use FUSE) so it is fine for browsing root owned files hassle-free. The only problem with this is that I may have missed an application not knowing that it accesses a network, but I'm fairly sure I havn't.

If I logged in as connor and somehow got a rootkit, that rootkit could only delete /home not /. If I logged in as root and got a rootkit, that rootkit could delete everything, but my most important data is in /home anyway so it makes no difference. This is the best of both worlds so the only vectors for getting rootkits are run as connor while I enjoy the convenience of running mainly as root. Not very conventional so I'll understand some disagreement, but right now I see no possible security holes.

Last edited by ConnorBehan (2007-09-27 23:34:27)

iphitus · 2007-09-25 08:30:46

I think you're missing the point.

Security isnt about making a bulletproof wall. It's about having layers, so that if one is breached, there's still a few to go. You've just effectively removed a layer.

Take any file format, create a malicious file exploiting anything, and any of your local, image viewers, file compression apps, video apps, are all now vulnerable to a system wide exploit. That's just one vector I can think of, and I'm definitely sure there's others.

IMHO, there's better ways of dealing with this, like extending the ticket time of sudo. Typically you'll do things as root in a period of time. Thus if you extend the sudo ticket time, you won't get asked for your password as frequently.

Secondly, what commands do you frequently use as root? I allow myself to sudo pacman and shutdown as a user without password.

Further, if you have your system setup, you shouldn't need to be using root so frequently. Question why and what you're using root for and see if you can do it as a user.

James

retsaw · 2007-09-25 09:15:31

If you log in a a user and get a rootkit it won't be able to do anything because a rootkit's goal to to take over your computer without you knowing, granted there might be other malicious software that could wipe out your ~/, but a rootkit most likely wouldn't. You need to be root to install a keylogger on Linux, so if you run as root and get infected you might not even realise then you use your computer for online banking and you have in effect given away the key details for your bank account, if you run as an unprivileged user it is much harder for this to happen.

It's your computer so use it how you want, but don't fool yourself into thinking the way you are working is just as secure.

Using sudo to run pacman without a password is quite insecure since a knowledgeable attacker could create a custom package with a suid binary that gives them root and use pacman to install it without needing a password. Is there a reason why I'm wrong in that statement or is there a way round it, since I do use sudo to run pacman passwordless anyway?

iphitus · 2007-09-25 10:12:27

retsaw wrote:

Using sudo to run pacman without a password is quite insecure since a knowledgeable attacker could create a custom package with a suid binary that gives them root and use pacman to install it without needing a password. Is there a reason why I'm wrong in that statement or is there a way round it, since I do use sudo to run pacman passwordless anyway?

No, you're quite correct. I figure the benefit here far outweighs the risk. It'd take a quite specific attack to exploit, and needs local shell access to install the package. Local shell access generally means game over anyway.

James

alexmatos · 2007-09-25 12:39:58

I have an analogy for computers security. Using Windows is like having sex without using condoms: it can feel better and be easier, but is it really safe? Using 'su' or 'sudo' is like putting on a condom before having sex: you have to waste a couple of seconds on it, but you're free to enjoy the rest of your time without having to worry.

test1000 · 2007-09-25 13:20:22

you could always just alias your favorite root cmds to sudo aswell... (what's up with sudo's syntax btw?? the op program actually seems understandable...)

ConnorBehan · 2007-09-25 23:12:02

Yes there are many possible ways for having security and not being bothered too much by it... I just thought this was a good balance of both. I can only get a keylogger or a rootkit or any piece of malicious software for that matter if a) I write it myself which I cannot and will not do or b) It's through an exploit in a program that listens to a protocol.

All my programs that listen to protocols are run as connor (except pacman). Therefore any malicious software I contract through them should have limited privileges as well right? Like I said, unconventional but I see no real security holes so I'll share this plan if anyone's interested.

smoon · 2007-09-26 08:29:58

ConnorBehan wrote:

Yes there are many possible ways for having security and not being bothered too much by it... I just thought this was a good balance of both. I can only get a keylogger or a rootkit or any piece of malicious software for that matter if a) I write it myself which I cannot and will not do or b) It's through an exploit in a program that listens to a protocol.
All my programs that listen to protocols are run as connor (except pacman). Therefore any malicious software I contract through them should have limited privileges as well right? Like I said, unconventional but I see no real security holes so I'll share this plan if anyone's interested.

You should be aware of the fact that every program that deals with data in any way can have exploitable bugs. That could be your image viewer, mediaplayer or even some program that just listens to keystrokes.

YithianHistorian · 2007-09-26 12:07:50

So your convenient solution is to log in as root, but tag a `gksu -u connor` in front of every command you run? Forgive me if I sound condescending, but isn't that more trouble than occasionally typing `sudo` to be able to edit a config?

Cerebral · 2007-09-26 13:25:52

The issue with your setup is that you've moved from a default-deny security model to a default-allow.

default-deny means that no program can run as root unless you specifically say it can (with sudo, for example)
default-allow means that EVERY program can run as root unless you specifically say it can't (with your gksu -u connor trick)

Just by those descriptions it should be clear which is more secure.

Say an exploit in your video player becomes known, and a few people craft videos that contain the exploit. You obtain one of those videos (it's your favourite band! How could you not get their latest concert vid?) and run it in your video player - which you run as root because it doesn't listen on any network ports, because you've shut that down - and suddenly malicious code is running on your system. The same can happen with any program that reads data - image viewers, movie players, document readers, and so on. Just because you run your web browser as 'connor' doesn't mean everything you download is un-privileged.

Here's an ok site about why default-allow is a bad model (apologies for the harsh title, it was the best I could find through google): http://www.ranum.com/security/computer_ … ials/dumb/

Anyway, it's your choice how to run your system, but the way you're doing it certainly isn't very secure.

.:B:. · 2007-09-26 13:47:42

I suggest a topic change, this is not secure at all. Some Microsoft devs hug the 'drop my rights' concept too, and it is hopelessly flawed.

ConnorBehan · 2007-09-27 04:11:25

YithianHistorian wrote:

So your convenient solution is to log in as root, but tag a `gksu -u connor` in front of every command you run? Forgive me if I sound condescending, but isn't that more trouble than occasionally typing `sudo` to be able to edit a config?

I only tag a gksu -u connor in front of NETWORK commands that I run... because I previously claimed that a program with no access to a network is safe to run as root no matter how many programming flaws it has. However I was wrong.

I guess you people have convinced me that this is not the case... the problem isn't running the program itself, the problem would be opening a file that takes advantage of a security hole. Thanks for that movie player example... I guess if I got a maliciously coded movie file from the web, the movie could contain a program inside it (or something like that?) And of course I wouldn't run a program that a movie file came with... if I even notice it's there I'd be like wtf? But I suppose the movie could be written so that opening it in Mplayer or VLC starts the program if there is a flaw in Mplayer or VLC. And now the program that got turned on by programs not listening on ports WILL start listening on ports. And this will be more catastrophic since I ran Mplayer or VLC as root rather than connor.

Ok, maybe I will switch back but then I will have to use the Terminal or run dialog whenever I want to start a program as root because icons will all be connor. I guess I'm too used to windows if I consider this inconvenient.

Having said that, how likely is it that exploits will be found in programs like VLC and Mplayer? I thought the fact that such programs are open source decreases this chance tremendously - I don't mean FOSS programmers are more ethical (I'd like to believe that) I just think more people looking over the code will catch those mistakes. Also, if an exploit in a program allows a file that it opens to start an unwanted process... that file is more or less a "virus". If I use AVG, do you think the updates of virus definitions will consider these threats? I'm fairly sure there are certain file types that are completely incapable of being viruses... There is no such thing as a JPEG that starts a process... right? I know M$ word documents and other more complicated documents can but to me this risk seems miniscule.

cactus · 2007-09-27 05:44:36

This is a bad idea.
If any new people run across this post, please note: This is a bad idea. Don't do it.

ConnorBehan · 2007-09-27 06:18:58

Alright I should never have said this is secure. What I mean is: running network processes as user while running everything else as root is a little more secure than just running everything as root.

But it also requires that you don't screw around with essential system files and that you know exactly which processes can access a network without forgetting any. So yes new people should run as a user which is more secure anyway. (Just how much more secure depends on how many files you have from untrusted sources and how many of your apps have exploits particularly alpha and beta releases).

In my case I don't think this solution predisposes me to THAT many more threats than least user access but:
1. I may be wrong
2. Even if I'm right, everyone's case is different

klixon · 2007-09-27 07:37:28

You might want to edit your first post, so that the first line reads:
Warning: Please read through all replies before you try this approach... There are strong suggestions from devs to not try this at home

adlucem · 2007-10-02 02:31:18

ConnorBehan wrote:

it is my icons that gave me trouble. I would click on the gedit icon, open xorg.conf, then realise that it was started with insufficient permissions, have to close it, open up the terminal and type sudo gedit, or type sudo chown connor /etc/X11/xorg.conf, save, then type sudo chown root /etc/X11/xorg.conf. Kind of a waste of time if you edit these files as much as I do.

PCLOS had a neat feature that would easen your life while not giving up any security (I think): when right-clicking on a file, you had the option to "Open as root": you'd enter the root pwd and the file would open. No need to open a terminal and type in a command.
I'm a noob so I don't know if it can be replicated easily on some of Arch's filemanagers.

pelle.k · 2007-10-02 10:56:06

adlucem wrote:

ConnorBehan wrote:
it is my icons that gave me trouble. I would click on the gedit icon, open xorg.conf, then realise that it was started with insufficient permissions, have to close it, open up the terminal and type sudo gedit, or type sudo chown connor /etc/X11/xorg.conf, save, then type sudo chown root /etc/X11/xorg.conf. Kind of a waste of time if you edit these files as much as I do.
PCLOS had a neat feature that would easen your life while not giving up any security (I think): when right-clicking on a file, you had the option to "Open as root": you'd enter the root pwd and the file would open. No need to open a terminal and type in a command.
I'm a noob so I don't know if it can be replicated easily on some of Arch's filemanagers.

I don't know how you missed it, but this is already available in nautilus, and with konqueror you can easily add these service menus;
http://www.kde-apps.org/content/show.ph … tent=48411

Shaika-Dzari · 2007-10-02 12:37:29

I'm simply using a root console when I must have root access and I launch every program I need from it.
I log and give my password one time, I do what I must do and close the console after that.

I don't really understand why you want to start X as root...

Arch Linux

#1 2007-09-25 03:15:17

Something I thought was secure but people have convinced me otherwise

#2 2007-09-25 08:30:46

Re: Something I thought was secure but people have convinced me otherwise

#3 2007-09-25 09:15:31

Re: Something I thought was secure but people have convinced me otherwise

#4 2007-09-25 10:12:27

Re: Something I thought was secure but people have convinced me otherwise

#5 2007-09-25 12:39:58

Re: Something I thought was secure but people have convinced me otherwise

#6 2007-09-25 13:20:22

Re: Something I thought was secure but people have convinced me otherwise

#7 2007-09-25 23:12:02

Re: Something I thought was secure but people have convinced me otherwise

#8 2007-09-26 08:29:58

Re: Something I thought was secure but people have convinced me otherwise

#9 2007-09-26 12:07:50

Re: Something I thought was secure but people have convinced me otherwise

#10 2007-09-26 13:25:52

Re: Something I thought was secure but people have convinced me otherwise

#11 2007-09-26 13:47:42

Re: Something I thought was secure but people have convinced me otherwise

#12 2007-09-27 04:11:25

Re: Something I thought was secure but people have convinced me otherwise

#13 2007-09-27 05:44:36

Re: Something I thought was secure but people have convinced me otherwise

#14 2007-09-27 06:18:58

Re: Something I thought was secure but people have convinced me otherwise

#15 2007-09-27 07:37:28

Re: Something I thought was secure but people have convinced me otherwise

#16 2007-10-02 02:31:18

Re: Something I thought was secure but people have convinced me otherwise

#17 2007-10-02 10:56:06

Re: Something I thought was secure but people have convinced me otherwise

#18 2007-10-02 12:37:29

Re: Something I thought was secure but people have convinced me otherwise

Board footer