News Group Posts

Bela Lubkin wrote:

> Tony Lawrence wrote:
> 
> 
>>A customer just pointed out the following to me:
>>
>>If you give a user "passwd" authorization, he can change passwords for 
>>other users but not root.  So far, so good, but if you want that user to 
>>use scoadmin, you have to ggive him "auth" to run Account Manager. 
>>Unfortunately Account Manager will now happily let him change root's 
>>password.
>>
>>Handy but not desirable, I think.
>>
> 
> Someone who controls all accounts except root will only be slowed down
> for a few seconds.  They can give a password to account "bin", login,
> replace /bin/sh with a trojan horse, wait for root to login (or a cron
> job to run).  And a thousand variants.
> 
> This is like giving someone the key to your store and the code for your
> alarm system, but not the key to the in-store safe.  Either you trust
> him or you don't.  If he's not trustworthy, he could walk in, turn off
> the alarm, and spend as much time as he wants trying to crack the safe.
> It wouldn't make much difference if you just handed him your "store"
> keyring with everything on it.

I seldom disagree with you, but this time I'm going to.

As someone said many years ago, the point of locks is to keep honest 
people out.

Dave Dickerson wrote:

 > On Thu, 03 Jan 2002 10:37:35 GMT, Tony Lawrence <tony@aplawrence.com>
 > wrote:
 >
 >
 >> Bela Lubkin wrote:
 >>
 >>
 >>> Tony Lawrence wrote:
 >>>
 >>>
 >>>
 >>>> A customer just pointed out the following to me:
 >>>>
 >>>> If you give a user "passwd" authorization, he can change
 >>>> passwords for other users but not root.  So far, so good, but
 >>>> if you want that user to use scoadmin, you have to ggive him
 >>>> "auth" to run Account Manager. Unfortunately Account Manager
 >>>> will now happily let him change root's password.
 >>>>
 >>>> Handy but not desirable, I think.
 >>>>
 >>>>
 >>> Someone who controls all accounts except root will only be
 >>> slowed down for a few seconds.  They can give a password to
 >>> account "bin", login, replace /bin/sh with a trojan horse, wait
 >>> for root to login (or a cron job to run).  And a thousand
 >>> variants.
 >>>
 >>> This is like giving someone the key to your store and the code
 >>> for your alarm system, but not the key to the in-store safe.
 >>> Either you trust him or you don't.  If he's not trustworthy, he
 >>> could walk in, turn off the alarm, and spend as much time as he
 >>> wants trying to crack the safe. It wouldn't make much
 >>> difference if you just handed him your "store" keyring with
 >>> everything on it.
 >>>
 >>
 >> I seldom disagree with you, but this time I'm going to.
 >>
 >> As someone said many years ago, the point of locks is to keep
 >> honest people out.
 >>
 >>
 >>
 >>
 >> -- Tony Lawrence SCO/Linux Support Tips, How-To's, Tests and more:
 >> 
 >>
 >>
 >
 >
 > Is this not one reason why there are surveillance cameras in stores and
 > audit subsystems in operating systems?

Further, why have authorizations at all if it cannot be made secure?  By
Bela's logic, the OS just shouldn't do that period because it's yet
another place where someone might subvert security.

Pardon me for saying this, and I really mean no disrespect, but that's
"engineer's logic".  Administrator's desire the ability to dole out
authorizations, and expect that as much safety as possible be built in.
That's a reasonable expectation.

The "passwd" auth doesn't allow changing the password of root or any
other user having passwd authorization.  It shouldn't allow the changing
of bin and other system accounts either but it does.  Anyone
administering a system would say that's a flawed system.  Perhaps it
cannot be made 100% secure, but it should certainly be better than that-
and I'm quite sure that it could be made so.

Scoadmin account manager won't run without "auth". With auth, it allows
any password to be changed.

This is a undesirable feature of Scoadmin Account Manager.  Period.



-- 
Tony Lawrence
SCO/Linux Support Tips, How-To's, Tests and more: 

Comments?

More Articles by Tony Lawrence

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.