Donate

Categories

Advert

XHTML

Valid XHTML 1.0 Transitional

Never IRC as Root

Ben Fowler blogs about the issues related to running IRC as root. Google searches for (irc client exploit) and (irc client “buffer overflow”) give a number of interesting web pages. Many of the exploits require the user to perform an action that’s slightly unusual, but why take a chance?

The advice to not run as root while generally sensible (run everything with minimum privileges as much as possible) is IMHO not very useful in recent times (and probably was never very useful). Generally when a user is worried about system compromise they are not worried about attackers having direct hardware access, the ability to corrupt system files, etc. They are worried that the attacker might read their email and access other personal files.

Therefore the instruction should be “don’t run IRC as root or as any account that has access to data which is important to you“. It’s not difficult to start an X-term that runs “exec su – ircuser irc” or “ssh -t ircuser@localhost irc“. Note that the -t option is required for ssh to make it allocate a pty even when receiving a command to run. Note also that in the case of su you need the exec option so that if the irc client is compromised and tries to perform a ioctl(0, TIOCSTI… based attack then it won’t succeed.

In any of these methods make sure that X access is not granted. Until we get Security Enhanced X working in a viable manner any process that can display an X window on your screen can own you totally. There are of course relatively safe ways of doing X, I have previously documented how to configure the Xephyr X server (replacement for Xnest) to allow a process with a different security context to safely display a graphical window on your desktop.

Generally I recommend not using a graphical X client on an untrusted network (IE anything other than an Intranet IRC server). I prefer to do my IRC in an account that’s not even on a machine that I care about and have it run screen so I can disconnect and re-connect from anywhere in the world.

When I first got SE Linux in Debian to be useful (when I could boot and run all programs without problem) I logged on to some IRC channels related to Debian with the security context of root:user_r:user_t. I admit that my actions in this regard could possibly be described as trolling, but I wanted to demonstrate what SE Linux can do. Unfortunately of the many people who told me off for logging in to IRC as root, none of them wanted to hear an explanation of why user_r is safe in this regard. I expect that most of them were running their IRC client in the same Unix account that was used for their email etc (and probably most of them had GPG keys accessible from such an account).

Sigh, it’s so easy to run IRC as a different user – in fact it’s probably the easiest of all network client programs to run in such a manner. There’s no reason not to.

8 comments to Never IRC as Root

  • You say that it’s easy, but I just don’t see how that is the case. You presented three methods of accessing IRC more safely:

    1. su to a restricted user.
    2. ssh to a restricted user.
    3. Restricted SE Linux context.

    #1 and #2 are two methods of implementing the same solution. Both require root access to create an independent account. #3 is the only one without a one-line example. (simple, elegant, and wrong) Can you perhaps link to a simple tutorial?

    My experience leads me to believe none of these solutions could be implemented by someone without technical experience – and each requires root permissions for staging.

    Is there a solution for the average user that doesn’t require root permissions?

  • […] Never IRC as Root » This Summary is from an article posted at etbe on Sunday, August 26, 2007 Ben Fowler blogs […]

  • etbe

    Both 1 and 2 can be easily implemented by anyone who might consider running irc as root.

    If someone has no root access on any machine then they can usually get multiple user accounts if they wish. The last time I lacked root access was when using time sharing systems at university, I had accounts on several machines and used them for different tasks – mostly for convenience but there were some security benefits too.

    3 is a default configuration of the SE Linux strict policy. I’ll start writing about that when I have it working well in Debian again.

  • Yes, someone who could run as root can easily not.

    I was thinking about users who don’t have root access. University accounts, the typical office worker, and younger family members are examples. Personal data protection is what I’m thinking about.

  • etbe

    For office workers all protection ultimately comes down to what the sys-admin provides. In that case probably the best they can do is refer their sys-admin to my blog post.

  • niq

    Erm .. simple up to a point but no further …

    Some of us use an IRC client that’s well-integrated with the desktop. So the acid test seems to be (in outline):

    # adduser irc-client
    # chown irc-client /usr/bin/konversation
    # chmod 4755 /usr/bin/konversation

    Now we can tweak irc-client’s privileges to exactly what’s needed and no more. But it doesn’t work: the client declines to run, at which point “Can’t Be Arsed” becomes a seductive option.

  • etbe

    niq: konversation is a bad example. Unless you use xephyr there is no good way of restricting the access granted to an X client at the moment. Also a setuid program does not lose access to it’s former UID, the setuid bit ADDs privileges and does not remove any. Some programs that are not designed to be setuid will recognise this situation and drop privs.

    I’ll have to write a separate post about setuid programs.

  • dud3

    i don’t know, the whole conservation sucks to me.. “not every linux also has a hacker init!” :-D

    dud3