Re: root users

From: Jeff Vian (jvian10_at_charter.net)
Date: 04/20/04

  • Next message: Jeff Vian: "Re: yum update 2179 kernel" 
    Date: Mon, 19 Apr 2004 21:00:46 -0500
To: For users of Fedora Core releases <fedora-list@redhat.com>

    Cris Rhea wrote:

    >>Here is a situation where this does not make sense, and the use of sudo
    >>does make sense
    >>
    >>1. Multiple users with root authority.
    >> john, bill, and sam
    >>
    >>one of these 3 happens to get mad/upset/frustrated/careless
    >>This user (lets say john) logs in and runs some commands that are very
    >>destructive to the system
    >> (have you ever heard of "rm -rf /" being run????)
    >>All three users actions are recorded as being done by root, thus no way
    >>to track who did what or when.
    >>The analysis of the problem shows that "root" did some
    >>dumb/careless/harmfull things to the system.
    >>
    >>Who is responsible????? Answer: one of the above
    >>
    >>2. One closely guarded root account with multiple users allowed the same
    >>access with sudo.
    >> again, users john, bill, and sam (but none of these users know the
    >>root password)
    >>
    >>The same user decides to do the dirty deed he did in the above scenario.
    >>Sudo actions are logged by user name, the user only has limited
    >>privledges when not using sudo.
    >>John now uses sudo to do his dirty work, and it is logged by user
    >>name/time/command
    >>Analysis shows john did the nasty deed.
    >>
    >>Who is responsible????? Answer: john.
    >>
    >>
    >
    >
    >IMHO, sudo works great if you need to give out a very limited set of
    >privs to a specific non-system admin (e.g., an applications programmer
    >responsible for a package that needs root privs to start).
    >
    >Also, IMHO, system admins need two things:
    >
    > 1. A clue as to what they're doing.
    >
    > 2. They need to be trustworthy and have the trust of management.
    >
    >If you have someone in your company who would intentionally destroy
    >a system with something like "rm -rf /", they have no business being a
    >system admin- period.
    >
    >
    I agree with both.

    However, there is always the time when a trusted individual goes whacko,
    or for some other reason decides to do something that will hurt. Or
    when someone who has high level access decides to use it for something
    other than his job with the expectation of not getting caught.
    (industrial espionage anyone?)

    Have you ever hears of the common procedure in the IT industry where
    when an employee gives a 2 week notice they are often excorted to the
    door and paid for the 2 weeks? Or the case where an employee being let
    go is handed his notice and escorted out?

    These are simple security features/procedures based on what might (or in
    some cases has) happen if they are allowed access under less than ideal
    conditions.

    Bottom line: Security procedures and policies often come at the cost of
    some inconveniences.
    You sacrifice some security or you sacrifice some convenience. Your
    choice what is right for you.

    Jeff

    >It all comes down to trust. You need to be able to trust your system admins.
    >If you can't, your company has real problems.
    >
    >Having multiple root logins is no big deal if someone isn't trying to
    >cover things up. There are lots of logs that indicate which "root login"
    >was active at the time. If you have someone intentionally covering things
    >up, they can modify the log files too... :)
    >
    >Yes, accidents happen, but a real system admin takes responsibility for
    >an "Oops" and fixes things. A really, really good system admin fixes things
    >before anybody figures out things are broken... :)
    >
    >Junior system admins should not have access to critical, production servers.
    >They should hone their "root" skills by building servers (prior to going
    >production) under the mentorship of a senior admin. The next step would be
    >to manage non-critical servers themselves (again, under the mentorship of
    >a senior admin). A responsible admin knows their limits and asks for help
    >if they get into a situation over their head.
    >
    >My $0.02.
    >
    >--- Cris
    >
    >
    All good points.

    >
    > 

    -- 
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
  • Next message: Jeff Vian: "Re: yum update 2179 kernel"

    Relevant Pages

    • Re: Easy way/script to add another user like me?
      ... have to do to give a user sudo privileges is to add them to the ... # Members of the admin group may gain root privileges ... of cracking the root password because they already know the ...
      (Ubuntu)
    • Re: Easy way/script to add another user like me?
      ... do to give a user sudo privileges is to add them to the admin group. ... I used my root account to add joker to the "admin group" via ...
      (Ubuntu)
    • Re: How do I give root permissions to another user?
      ... It sounds like your sudo isn't properly configured. ... That you could perhaps do with making a new group 'admin', ... people will have different rights. ... However, if you do it correctly, nobody will actualy need the root ...
      (alt.os.linux.suse)
    • Re: Admin account suddenly changing to a standard one
      ... root password by typing su at the terminal's prompt. ... (with admin privileges, ... the system I could login but the account whose short name I changed - the ... sudo command gives you temporary root access, ...
      (comp.sys.mac.system)
    • Re: Terminal wont let me write superuser password
      ... To do that you need admin (or superuser) rights. ... All you'd need to do is the type ' sudo ', ... or use ctrl+alt+f1 to drop to a VT as root (use ...
      (comp.os.linux.misc)