authorization auth passwd scoadmin

If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):

From: Bela Lubkin <belal@caldera.com>
Subject: Re: Authorization hole?
Date: Fri, 4 Jan 2002 07:22:43 GMT
References: <3C3396DE.9070008@aplawrence.com> <20020102191943.A8455@mammoth.ca.caldera.com> <3C3434C7.80204@aplawrence.com> <3c343ec2.3133706@news.earthlink.net> <3C34648F.90909@aplawrence.com> 

Tony Lawrence, Dave Dickerson and myself wrote:

Tony>>>>> If you give a user "passwd" authorization, he can change
Tony>>>>> passwords for other users but not root.  So far, so good, but
Tony>>>>> if you want that user to use scoadmin, you have to ggive him
Tony>>>>> "auth" to run Account Manager. Unfortunately Account Manager
Tony>>>>> will now happily let him change root's password.

Bela>>>> Someone who controls all accounts except root will only be
Bela>>>> slowed down for a few seconds.  They can give a password to
Bela>>>> account "bin", login, replace /bin/sh with a trojan horse, wait
Bela>>>> for root to login (or a cron job to run).  And a thousand
Bela>>>> variants.
Bela>>>>
Bela>>>> This is like giving someone the key to your store and the code
Bela>>>> for your alarm system, but not the key to the in-store safe.
Bela>>>> Either you trust him or you don't.  If he's not trustworthy, he
Bela>>>> could walk in, turn off the alarm, and spend as much time as he
Bela>>>> wants trying to crack the safe. It wouldn't make much
Bela>>>> difference if you just handed him your "store" keyring with
Bela>>>> everything on it.

Tony>>> I seldom disagree with you, but this time I'm going to.
Tony>>>
Tony>>> As someone said many years ago, the point of locks is to keep
Tony>>> honest people out.

Dave>> Is this not one reason why there are surveillance cameras in stores and
Dave>> audit subsystems in operating systems?

Tony> Further, why have authorizations at all if it cannot be made secure?  By
Tony> Bela's logic, the OS just shouldn't do that period because it's yet
Tony> another place where someone might subvert security.
Tony> 
Tony> Pardon me for saying this, and I really mean no disrespect, but that's
Tony> "engineer's logic".  Administrator's desire the ability to dole out
Tony> authorizations, and expect that as much safety as possible be built in.
Tony> That's a reasonable expectation.
Tony> 
Tony> The "passwd" auth doesn't allow changing the password of root or any
Tony> other user having passwd authorization.  It shouldn't allow the changing
Tony> of bin and other system accounts either but it does.  Anyone
Tony> administering a system would say that's a flawed system.  Perhaps it
Tony> cannot be made 100% secure, but it should certainly be better than that-
Tony> and I'm quite sure that it could be made so.
Tony> 
Tony> Scoadmin account manager won't run without "auth". With auth, it allows
Tony> any password to be changed.
Tony> 
Tony> This is a undesirable feature of Scoadmin Account Manager.  Period.

I thought (well, let's say "had the vague impression") that the "passwd"
authorization carried over to `scoadmin account`; that is, having
"passwd" would let you manipulate accounts via scoadmin, but not ones
that themselves had "passwd".  If this is not the case, it's a bug in
scoadmin.

Anyway, I thought that you already had three settings on the knob: no
able to run `scoadmin account`; able to, but restricted from certain
accopunts; and unrestricted.  I didn't realize the knob was broken and
only had two settings.

Maybe my vague memory comes from the behavior of the old sysadmsh?  You
can still install that -- I don't have the patience to play with it
right now, but if you do, you could research whether it pays attention
to "passwd" auth; if so, that's a workaround.  Besides, the sysadmsh
user editor is so much better than the scoadmin one...

>Bela<
 

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.