[ale] bash commands

Lightner, Jeff JLightner at water.com
Wed May 23 14:12:27 EDT 2012


I didn't accuse you of not being a SysAdmin  or working in your dorm room - I responded to the implication that possibly I wasn't one.   (Stating things like only right thinking people believe blah blah blah  implies that the person you're responding to is not a "right thinking person".)

Do I reread an entire thread every time I responding to the latest post in it.  No.  Do you?   Is there a reason you feel you have to get personal?   If so let me reciprocate.

I fear you are being deliberately obstinate in your refusal to see a difference.    The difference between the root account and application specific accounts is vast.   DBAs by and large need access to databases which are owned by DB specific accounts.   Application specialists often need to share access to specific applications but nothing else.   Giving diverse groups access via sudo to only those accounts they need limits them to those particular areas of responsibility without giving them full access to all other areas on the system as root would.      Having worked in many environments that have had many separate functional areas the difference is quite clear to me even if it isn't to you.  

-----Original Message-----
From: ale-bounces at ale.org [mailto:ale-bounces at ale.org] On Behalf Of Brian Mathis
Sent: Wednesday, May 23, 2012 11:37 AM
To: Atlanta Linux Enthusiasts
Subject: Re: [ale] bash commands

You clearly still haven't read or referred back to my original post, so I will quote it here:
    You still need to keep track of the root password, but
    now you can set it to some long random string and keep
    it locked in a safe* somewhere

This deals with the issue of getting into a system in an emergency, and frankly, this is such an obvious objection that I addressed it in my first reply.  * I'm using the word "safe" here to refer to any secure method of storage.

As far as application accounts vs the root account, what's the difference, other than creating a special one-off policy that only applies to root?  A sysadmin has to manage resources and policies (which it seems I wasn't clear enough about) and every special case policy is another thing you need to manage.  If you use the same policy for as many cases as possible, especially given the clear advantages, then that's a win for increasing efficiency and in this case, security.


❧ Brian Mathis

P.S. You make a poor mind reader in this instance.  The tone and lack of mindlessly repeating dogma in my previous posts should have tipped you off that I'm not just running Linux in my dorm room.


On Wed, May 23, 2012 at 10:17 AM, Lightner, Jeff <JLightner at water.com> wrote:
> I disagree that UNIX admins shouldn't know the root password.   Sometimes the only way to get into a system is via root on the console.   (Of course I'm talking about without first doing a reboot - sometimes a reboot is the worst thing you can do.)   By POLICY admins shouldn't login as root directly except in cases where they must but taking the root password away from admins in my view is just asking for extended downtime when major issues occur.
>
> The paragraph you mention as contradictory wasn't - the admin accounts I was speaking of were application specific and NOT the root account itself.
>
> After 21 years I think I'm probably safe in calling myself a SysAdmin.  
> Heck I even have a certificate from RedHat that calls me a "Certified 
> System Administrator" :-)   (Thats on top of tons of training on 
> various other flavors of UNIX and associated applications and hardware 
> such as NetBackup. EMC and Hitachi.)
>
> You point about management vs administrator is a bit specious.  Certainly SysAdmins are expected to "manage" things but many employers are quite happy to rely on them to fix serious issues without bothering to ask for or accept their input on how to prevent such issues in the first place.
>
> So the next reply will likely be: " If you work in a place like that get a new job."
> That particular piece of advice is often tossed around by people that don't work in real world environments where the Systems Administration team is NOT the tail that wags the dog.
>
>
> -----Original Message-----
> From: ale-bounces at ale.org [mailto:ale-bounces at ale.org] On Behalf Of 
> Brian Mathis
> Sent: Wednesday, May 23, 2012 9:44 AM
> To: Atlanta Linux Enthusiasts
> Subject: Re: [ale] bash commands
>
> On Mon, May 21, 2012 at 8:44 AM, Lightner, Jeff <JLightner at water.com> wrote:
>> I disagree with the purpose of sudo stated previously.  It was not 
>> designed to prevent System Admins from getting root access.  It was 
>> designed to allow NON-system admins to access only those few things 
>> they need as root without giving them the root password and full root access.
>
>
> I understand how the purpose of sudo seems somewhat muddy -- after all, all we UNIX folk like to think of each tool as having only one purpose, unless it's a programming language or something.  Sudo can be unclear because it provides a few different functions:
>    - Limit users to running only some commands as root
>    - Provide an audit trail of who executes what commands as root
>    - Remove the need for anyone to know the root password Those who don't like the idea of sudo often grab onto one or two of these uses to make a point, but completely ignore the others.
>
>
>> Over time PHBs have somehow decided that even System Admins shouldn’t 
>> have root which is why you see abominations like “sudo” only distros.
>> System Admins do spend a lot of their time as root no matter how much 
>> hand wringing is done by people that like to claim it isn’t secure.
>
>
> You seem to be confusing "Management" with "those who manage".  If you're a sysadmin then you are in the second category, at least you better be otherwise you're just a techie who happens to get paid for it.  As already stated, sudo is a very big help to anyone managing root passwords.  Please see my previous email about this.
>
> No one should be using shared accounts or know the root password, because whenever the team changes you have to change the passwords and tell everyone the new password (except each system should have a different root password, so have fun with that).
>
>
>> The sad thing about sudo is how many admins do not seem to understand 
>> what they’re giving to users with it.   The first place I saw it they 
>> gave users “sudo vi”.   I had to show them what “:!/bin/sh” did in 
>> such a session.   I also had to explain to them why sudo access to 
>> shell scripts that were not writable only by root in a directory only accessible by root was a bad idea.
>
>
> This is the typical security wonk "sudo sucks" argument.  In isolation, this back door is obviously a problem, but like any tool, you need to be aware of it.  However, it's really about the tool you are giving access to, not a problem with sudo itself.  There are plenty of modes where granting access to commands through sudo do not pose such a problem, so it's hardly the silver bullet argument that kills sudo.
>
>
>> I’ve only worked one place where I thought they handled sudo for 
>> Admins correctly.   They had syslog traffic going to a server NOT 
>> controlled by the Admins and any time you used sudo you had to put in 
>> a reason why and be prepared for a query from management because they 
>> got emails when you did it.   You could hide what you did after 
>> becoming root but not the fact that you HAD become root.
>>
>> We use sudo extensively here mainly for its (IMHO) original purpose.
>> One great use of it is to get rid of purely administrative accounts 
>> for applications where everyone knows the password.   By requiring 
>> users that need access to such administrative accounts to do “sudo su
>> - <account>” you can log which user became that administrative user 
>> right before everything went to hell in a handbasket.
>
>
> I'm not following here.  This last paragraph seems to contradict the first few.  What you are doing with it here is perfectly in line with the purpose of sudo, and what we have been talking about here.  Sudo provides auditing and the ability to remove shared passwords, including shared passwords to the root account.  It's the same thing.
>
>
>
> On Tue, May 22, 2012 at 6:27 PM, Jim Kinney <jim.kinney at gmail.com> wrote:
>> Big +1
>>
>> sudo is not a tool for admins.
>
>
> I'm not sure how you could be following this thread and still say that.  Despite these feelings about it, changes like this don't make headway into common practice without being reviewed by a great many security people.  As most distros have moved to this model, it appears that they disagree with you.
>
>
> ❧ Brian Mathis
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at 
> http://mail.ale.org/mailman/listinfo
>
>
>
>
> Athena®, Created for the Cause™
> Making a Difference in the Fight Against Breast Cancer
>
> ---------------------------------
> CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
> ----------------------------------
>
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at 
> http://mail.ale.org/mailman/listinfo

_______________________________________________
Ale mailing list
Ale at ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo



More information about the Ale mailing list