Re: "Bugbear" virus in Linux?

From: Sean G Gilley (uem_at_mycroft.cmhnet.org)
Date: 07/16/03 

Date: 16 Jul 2003 09:52:58 -0700

"Peter T. Breuer" <ptb@oboe.it.uc3m.es> wrote in message news:<kvt1fb.9rr.ln@news.it.uc3m.es>...
> Sean G Gilley <uem@mycroft.cmhnet.org> wrote:
> > I am one of several Unix admins in a relatively large corporation. Every
> > single one of our boxes allows root logins. Every single one of our boxes
> > allows 'su'. None of them allow remote root logins. I've been admining
> > Unix boxes since about 1984, and that's *always* been the standard I've been
> > taught and that I've used.
>
> It's insufficiently paranoid. Now you don't know that when there is a
> root login shell running if it is legitimate or not. I know that it is
> always NOT.

I think I could find quite a number of people who disagree that we're being
"insufficiently" paraniod. I would include in that the outside security
auditors for my corporation.

>> Now, perhaps it makes a difference that the other half of the equation is
>> that all the boxes are in secured locations.
>
> Not really. A hacker can login remotely as someone else and then run a root
> shell.

For a hacker outside my corporation to be able to get to one of my boxes, he
first has to break through the corporate firewall. Now, assuming he has access
to the internal network, he then has to figure out which of the several thousand
machines are servers as opposed to desktop machines. Next he has to figure
out which are the Unix boxes. Next he has to access the machine. As my machines
don't normally have users other than admins (they are servers, after all), he's
going to have to figure out a working login just to get into the system.

Now, if he *should* get that far, he'd better get the root password within
two attempts, because on the third attempt that fails, I, and several others,
get paged.

Further, my machines are scanned regularly by our security department to
indentify any known security holes. If they find a problem, the problem gets
patched.

>> I login as root. It's not the usual situation, as the boxes are anywhere from
>> a five minute to a ten minute walk from where I sit, but I do login as root.
>
> They should never do so. There is no need to do so. Apart from the fact
> that their actions are not logged, there is the problem that if you are
> prepared to let them run as root, you are prepared to let anyone run as
> root.

I'm prepared to let anyone run as root? No, I'm prepared to let any of
our admins run as root.

>> I disagree that it is a security risk, especially as
>
> Then you are wrong. The risk is manyfold. Apart from the obvious taht
> you don't have a record of what they have done, which is the minimal
> that any admin MUST have.

I disagree. I have stable machines. If I'm working on them su'd or as
root, I have a reason. I don't need a list of every command I or my
other admins type. I know what's happening on my machines. And if
someone should happen to screw up badly, I have good backups -- both on
and off site.

Further, if we really felt we needed to know everything an admin typed, we
run logging applications.

Given your description of sudo, I'd like to hear what additional risk there
is of allowing root access. I can think of one thing. If a hacker gets to
the console, then there is potentially a problem. Of course all my machines
are in locked rooms, and you need an employee pass to get into the building
where those locked rooms are...

> You should not - su is unsafe: it doesn't leave a record and it
> requires the use of the root password, thus it's exactly the same
> as a root login, which means that it is unsafe, for all the usual
> reasons.

Okay, if you are saying that you can do anything that needs to be done using
sudo, then you are saying that sudo is a complete substitution for su.
If so, then anyone who can use sudo can alter the log files and you'ld have
no more idea what happened on your system than you would with su.

I don't understand why you seem to feel that sudo is safer than su. It is
not, in a properly controlled system. Just because it logs actions doesn't
make it safer.

>> here for people who need to do certain tasks, but administrators are presumed
>> to be competent enough to use su.
>
> They aren't. Not normally, anyway.

Just because *your* company doesn't hire competent system administators,
don't assume my company works the same way. A while back I saw an admin
let go because of competency issues.

> Single user mode is never needed. It's only a name for a certain set of
> processes running. You can kill whatever processes you like by hand and
> start whatever ones you like. Yes, it's often a convenient way to kill
> off uneanted processes, but as often it is not - on most linux boxes,
> for example, it does way too much and leaves way too much running. I
> generally start up with just sshd running if I want to be minimal.

You've never seen a system that won't come up in multi-user level because of
system or disk problems? I don't go to single user level for fun -- I'm
talking about times when a system has crashed and there is no other way to
get the system running becuase it *can't* come up normally.

> NO, no single user mode (well, to be truthful, what I do is disable
> root login on anything except tty6, and only start a getty on tty6 in
> runlevel 1, and require the password to start up in runlevel 1 ... but
> I only do that to make the admins feel that they have some fallback,
> never mind the fact that they do anyway, via a boot disk, or
> init=whetever)>

When a production system that is a back end for records accessed by both
our company's customers and by internal personel is down in the middle of
the day, I darn well better get it back up as quickly as possible.

Here's what I do: I type the root password at the console or via the terminal
server and log in at single user level and fsck all my disks which probably
gets the system running pretty quickly, with at most one additional reboot.

Or, I could go find a boot cdrom, boot from cdrom, which involves going through
diagnostics again (which are not, on enterprise class machines, especially
fast), boot to an OS which will let me fsck the root filesystem and some
others, but not all, because I don't have drivers in this OS for my fiber
connected EMC drives, then reboot *again*, *again* going through diagnostics,
and get to a maybe usable system -- but safer would be to boot single user
and check all the filesystems, only to reboot *again* because sometimes going
from single-user directly to multi-user doesn't do all the right things.

>> In short, I really feel that saying that only irresponsible sysadmins log in
>> as root is ridiculous. And being forced to use sudo instead of su is even
>
> You feel wrong. It is irresponsible. What possible excuse can you have
> for logging in as root when you can do everything via sudo. One wants
> to discourage the use of root - make it as uncomfortable as possible to
> be root. That way an admin will think about every action as root.

It is not irresponsible. If you have competent admins, then logging every
action an admin takes simply isn't necessary. If you can't trust your admins
to act responsibly, then fire them and get ones you can. If you can't trust
yourself to act responsibly, then you shouldn't be doing admin work. You
want to log everything you do? There are other ways, even using su.

And if you do everything via sudo, how is it any different than su? Yes,
actions are logged, but admins aren't thinking any harder about what they
are doing just because they are using sudo. It becomes as routine as
anything else.

>> worse. If I'm working on an installation, or something else that take some
>> indeterined number of steps, am I supposed to preface each one of them with
>> an sudo command?
>
> Yes, you most certainly are. What's the problem with that?

Because I disagree that it does anything useful.

>> If that's what you want for your system, and your users and
>> admins put up with it, fine. If I tried to place a like scheme on one of
>
> There's nothing to put up with! "sudo echo hi" is no more painful than
> "echo hi", and it logs what you do. You will often see me do "sudo echo
> I\'m just going to edit foo in order to do bar", simply to provide a
> record of my intentions in the log. OK, I could use "logger" instead,
> but it's a quick way of putting it in the auth log.

I think I'd disagree, and I know that others here would disagree as well.
I think if I had to preface everything with 'sudo ' I'd write a program
that would do it for me. At the very least I'd write a ksh function that would.

Sean.

Relevant Pages

  • Re: NFS re-export
    ... Just because you have root on hostA does ... >>specific hosts that no one but the bu admins can login to. ... That sudo priviledge may extend to ... personally I never used the re-export option so ...
    (comp.protocols.nfs)
  • Re: Software configuration management tool required
    ... > SNMP should be looked to ... Development systems were essentially production environments where the ... One of the things they implemented was taking root away from everyone ... Some admins just won't like it and will rebel, ...
    (comp.unix.admin)
  • Re: Root Access
    ... good reason. ... but root login is allowed by default in upstream OpenSSH ... need to ssh in and create them (for those admins that don't have ... logging in to the Administrator account) with disasterous results. ...
    (Fedora)
  • RE: [Full-Disclosure] Removing FIred admins
    ... Only the senior administrator and the CTO have the root password to the ... The senior admin does not "own" and servers, ... manager for all of the other admins. ... > local and domain administrator passwords on our Unix and Windows ...
    (Full-Disclosure)
  • Re: to allow root logins or not?
    ... it asks if I want to allow root logins. ... sudo, but is there a downside to not having an actual root account. ... If you really want to not have root login, you would need to have a rescue CD or equivalent method of booting the system, to fix anything that couldn't be handled by a normal startup from the boot hard disk. ...
    (Debian-User)