# Re: xsane as root

From: Andreas Beck (becka@rz.uni-duesseldorf.de)
Date: Thu Feb 24 2000 - 18:15:34 PST

- Next message: Jason Joy: "Problems with UMAX, think I'm missing something elementary..."
  - Previous message: Bruce Burden: "Re: xsane as root"
  - In reply to: John Anthony Kazos Jr.: "Re: xsane as root"
  - Next in thread: Oliver Rauch: "Re: xsane as root"
  - Next in thread: Bruce Burden: "Re: xsane as root"
  - Reply: Oliver Rauch: "Re: xsane as root"
  - Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

  > Certainly. Because I am the only user of my system (besides my friends
  > logging in to share files or to talk), so there's really no reason to
  > not be root.

  There are. Many. When you are root, you have full permissions to all files
  and other stuff on your box. While this is right in the sense, that this
  might be what you want, it is not a good idea, as all programs that are
  acting on your behalf also get these priviledges.

  Now think about malicious programs. If you somehow catched a program
  infected with a virus (and yes, there are Viri for Linux), it can't do
  much damage, if you are not root. All important system binaries that might
  be run by other users later (and thus be used to spread the virus) are
  protected by the system. You can just infect your account and that's it.
  When you are root, the programs have full access and thus the virus can
  spread to its liking, destroy its traces, acess hardware to its liking
  (e.g. flash the BIOS to rubbish thus rendering your board unuseable until
  you get a replacement Prom from your vendor). Ever wondered why there are
  so few viri for Unixes ? Mainly because they don't spread well on Unix -
  due to this protection mechanism.

  O.K. - assumed you never get any programs from untrusted sources, and all
  your programs are benevolent.

  This does however not mean, that the programs are bug-free. Assume you have
  a program that writes some files to /tmp/something/*, uses them for a
  while and then deletes it using "rm -rf /tmp/something/".

  Now if that program has a buffer overflow and you happen to give it a string
  that is too long to it, you are quickly in a situation where
  "rm -rf /tmp/something/" becomes "rm -rf /", because the buffer that is
  located before the path array that usually holds "/tmp/something/" is
  overflowed by exactly two chars: "/\0" .... oops.

  Speaking of buffer overflows:

  There are quite some "passive" remote attacks, that e.g. rely on a user
  accessing a webpage or opening a mail. Again, if you are not root, you are
  relatively safe, as the amount of damage is limited to your account.

  > Everyone who talks to me spouts the old chestnut that you can really screw
  > up your system if you're root, but no one ever tells me how.

  I hope the stuff above convinced you. I can surely find qute some more
  examples and risks.

  I usually never log on as root except for certain maintenance tasks, where I
  will need root permission all of the time. For other stuff I will always
  stay root only as shortly as possible using su, sudo or similar.

  > Sure, I could type 'rm -rf /*' and my system would merrily go to hell,

  You could type "my_broken_program
  with_some/too_long_argument/that_overflows/_a_buffer_like_described_above/"

  and the system would do the same. Of course there is a little stupidity
  involved in this as well (i.e. writing a broken program and/or allowing
  a broken program on your system), but I think avoiding that little bit of
  stupidity is far too costly: Reading, understanding and fully analyzing
  each and every program on your system just to save some su calls ?

  > but really, if I'm stupid enough to type that, why am I using Linux?

  If you are stupid enough not to make use of the protection scheme Linux
  offers you, why aren't you using Windows ? Please don't take that
  personally. It isn't intended this way. I just want to make very very clear,
  that it is not a good idea to become root without need.

  > It would be infuriating to have to su every time I wanted to do anything
  > interesting besides using a program.

  Hmm - I thought that's what operating systems are for: Allowing us to use
  programs. Of course while you are learning to be a system administrator
  or similar, you might need to be root for extended periods of time, but
  other than that, I think using programs is, what one should do.

  If you frequently need a program that requires root priviledges to operate,
  it might be a good idea to
  1. Check if the program can't be stripped of that requirement (like by
  installing the LibGGI SVGAlib wrapper and then remove the suid-bits of
  all that SVGAlib apps).
  2. If that can't be done, you might consider using sudo.

  Note, that you can have a relatively quick way to log in and/or use su,
  if you trust at all local users: You can program some function key to be the
  root password. O.K. - everyone with console access can then log in as root
  (it won't work remotely, as there, the string will just send its usual
  ESC-Sequence), but someone with console access can do more damage by using
  a heavy object to redesing the system appearance.

  > If you can show me one good case where being the superuser will prevent *any*
  > disaster (major or minor) not due to stupidity, I will cease the practice
  > immediately.

  I hope the above examples are enough. It is really better for the health of
  your system. Believe me.

  There is yet another very simple case, where I would as well not call it
  stupidity if someone nukes all of his files:

  Say you want to do "rm -rf *~" like to remove joe's backup files. Now if you
  have dead keys on, you might end up typing
  "r m <space> - r f <space> * ~ <Enter>" instead of the correct
  "r m <space> - r f <space> * ~ <space> <Enter>".

  Not too stupid (maybe except for the -r) I think, especially if you usually
  work on nodeadkey machines ...

  Not being root will limit that desaster to quite some extent, depending on
  the current directory.

  O.K. - now for a word about running SANE as root: I'd opt for placing a big
  fat warning or some configuration file if desired. I generally do not think
  it is a good idea to restrict root from doing anything. It's the whole
  purpose of the "root" concept to be able to override all and everything.

  Root might be running xsane for testing purposes, and I think it would
  hinder testing to quite some extent, if root could not run xsane.

  Moreover, someone might write a usermode driver for some hardware using port
  access or similar. While I cannot recommend that for production use (that
  is what hardware drivers are for), it might be convenient for development.

  If running SANE as root is a security risk except for stupidity on root's
  part, that should be fixed in SANE or the underlying layer that causes the
  problem (like Linux' braindead behaviour to enumerate devices instead of
  using SCSI-IDs like most other Unixish OSes do).

  CU, ANdy

      --
      = Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =
      --
      Source code, list archive, and docs: http://www.mostang.com/sane/
      To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com

  - Next message: Jason Joy: "Problems with UMAX, think I'm missing something elementary..."
  - Previous message: Bruce Burden: "Re: xsane as root"
  - In reply to: John Anthony Kazos Jr.: "Re: xsane as root"
  - Next in thread: Oliver Rauch: "Re: xsane as root"
  - Next in thread: Bruce Burden: "Re: xsane as root"
  - Reply: Oliver Rauch: "Re: xsane as root"
  - Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

  This archive was generated by hypermail 2b29 : Thu Feb 24 2000 - 18:21:11 PST