Authorization hole?
Tony Lawrence
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.
--
Tony Lawrence
SCO/Linux Support Tips, How-To's, Tests and more: http://pcunix.com
Bela Lubkin
> 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.
>Bela<
Tony Lawrence
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.
steve overy
... assuming this is uw7/ou8, there is no reason why you should not
"adminrole" a script which validates which user account is being
changed (maybe even keep logs) before then using "expect" with
"passwd"... I suppose you could even tcl it to keep it gui friendly
steve
Dave Dickerson
wrote:
Is this not one reason why there are surveillance cameras in stores
and audit subsystems in operating systems?
DDinAZ
Tony Lawrence
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
Yes, and (although this is OSR5) that's pretty much what I came up with
as a stopgap solution, although in this case it may also involve
putting a fake "scoadmin" earlier in the user's PATH.
Bill Vermillion
>Is this not one reason why there are surveillance cameras in stores
>and audit subsystems in operating systems?
On really secure systems the duties can not be done by just one
login and sometimes adding a user requires two people. And others
who control other access can't add users.
The concept is the same as the people in the ICBM bunkers where it
took two people to turn the key.
Bill Vermillion
<to...@pcunix.com> wrote:
>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.
Since the OSR5 is getting to be close to being a legacy OS, and for
the last five years SCO has been the only vendor shiping a Sys V.3
product that I recall, is it worth the expense to go back and
retrofit into a system that was not designed with all of today's
security problems in mind? So while it may be possible is it
economically feasible as the newer OSes are usually better at this.
I'm not complaining about the way the product evolved because they
were under licensing constraints from Microsoft [because of Xenix]
that no other vendors of which I'm aware had to follow. [Possible
exception of Altos but theirs was supplied on their own HW].
>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.
I won't disagree with that - just saying that it may not be as easy
as you would like it to be.
Bela Lubkin
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<
Tony Lawrence
It's not the case, so it's a bug- the accounts manager needs "auth"
>
> 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.
Ayup.
>
> 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...
I have .less patience than you :-)
Bill Vermillion
Bela Lubkin <be...@caldera.com> wrote:
>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...
That is a major understatement. Scoadmin looks prettier but I
liked the old sysadmsh better.
Jean-Pierre Radley
I *always* load sysadmsh on any OSR 5 installation.
--
JP