> 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
This archive was generated by hypermail 2b29 : Thu Feb 24 2000 - 18:21:11 PST