norstar@tnl.UUCP (Daniel Ray) (03/05/89)
Hello everybody. I am trying to hack together a working equivalent to
the /etc/shadow scheme of unreadable passwords. I run a XENIX 386 v2.2.3
system, and only have a binary license. Working with the 'bpatch' binary
editor, I was planning to substitute the word 'shadow' for 'passwd' in
the text string appearances of '/etc/passwd' in the compiled object files
for: /bin/passwd, /etc/login, and /bin/su. (Then I would have cron periodic-
ally copy /etc/shadow to /etc/passwd except that the 2nd field would be
an 'x' in the public /etc/passwd version, while the real passwd file would
be /etc/shadow).
I think I could have made the scheme work except for one thing: /bin/passwd
does a chmod("/etc/passwd",444); somewhere before exiting, which is quite
proper for a PUBLIC passwd file. Only I want it to leave the mode as 400
for the substituted PRIVATE shadow file.
My question is: is there a way to use 'bpatch' on /bin/passwd so that I can
edit the mode 444 to mode 400. How would I identify the hex bytes that do
this chmod?? Is this more trouble than its worth (maybe I should find or
write my own /bin/passwd ???). I wish SCO and other UNIX sellers would
include the source code for these security-related programs as they do
for the UUCP dial program...as it stands now I'd have to fork over $60000
for the privilege! oh well..
Thanks if anyone can assist me in this!
dan
norstar
The Northern Lights, Burlington Vermont | Futility, like
tnl dialins: 802-865-3614 at 300-2400 bps. ` | / suffering, is
------------------------------------------ --- * --- a *hell* of a
uucp: uunet!uvm-gen!tnl!norstar or / | . lot of fun!
{decvax,linus}!dartvax!uvm-gen!tnl!norstar | (Try it you'll
like it!!)debra@alice.UUCP (Paul De Bra) (03/06/89)
In article <199@tnl.UUCP> norstar@tnl.UUCP (Daniel Ray) writes: >Hello everybody. I am trying to hack together a working equivalent to >the /etc/shadow scheme of unreadable passwords. I run a XENIX 386 v2.2.3 >system, and only have a binary license. Working with the 'bpatch' binary >editor, I was planning to substitute the word 'shadow' for 'passwd' in >the text string appearances of '/etc/passwd' in the compiled object files >for: /bin/passwd, /etc/login, and /bin/su. (Then I would have cron periodic- >ally copy /etc/shadow to /etc/passwd except that the 2nd field would be >an 'x' in the public /etc/passwd version, while the real passwd file would >be /etc/shadow). >... Wait a minute... this is not a useful way to implement /etc/shadow. The idea of /etc/shadow is to have a publicly accessible /etc/passwd that does not contain the (encrypted) passwords. /etc/shadow only contains the login and encrypted passwords (and possibly some other secret stuff). It is to prevent password hacking that the password should be in the unreadable file. I don't see much use for your copy of /etc/passwd. Maybe you want to reconsider the whole idea? Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (03/07/89)
In article <9004@alice.UUCP> debra@alice.UUCP () writes: | Wait a minute... this is not a useful way to implement /etc/shadow. | The idea of /etc/shadow is to have a publicly accessible /etc/passwd that | does not contain the (encrypted) passwords. /etc/shadow only contains the | login and encrypted passwords (and possibly some other secret stuff). | It is to prevent password hacking that the password should be in the | unreadable file. I don't see much use for your copy of /etc/passwd. | Maybe you want to reconsider the whole idea? I don't understand this response at all. The proposal was for a file (/etc/shadow) which would hold the real password and be readable only to root, and the standard password file (/etc/password) which had the same info with the password replaced by 'x'. This sounds like a totally workable solution. I see no reason why having non-secret stuff in the shadow file hurts anything... I just looked with a binary patch editor and found 4404 in the /bin/passwd program. Now I'll create a small dummy filesystem, patch the programs su, login, and passwd, and test under chroot. WHen I feel brave I'll actually install them. Totally great idea. The files only have to be copied when a uid is added/deleted, or comments, etc, are changed. Obviously chsh and friends will have to change if you have them. ================ Maybe SCO could pick up this idea - HINT ================ -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
debra@alice.UUCP (Paul De Bra) (03/07/89)
In article <13314@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: > I don't understand this response at all. The proposal was for a file >(/etc/shadow) which would hold the real password and be readable only to >root, and the standard password file (/etc/password) which had the same >info with the password replaced by 'x'. This sounds like a totally >workable solution. I see no reason why having non-secret stuff in the >shadow file hurts anything... Oops, I goofed while reading the message. Sorry about that. But, it may be a bit more tricky than you suspect though. You may want to check which other programs look in /etc/passwd to find the password. Like, what happens when you want to enter "maintenance mode" (in Xenix) ? And wouldn't you want routines like getpwent() to give you the real encrypted password when invoked by root or something? And what about other programs that may exist and change the password file, like chsh (don't know exactly which ones exist in Xenix). They too should change the shadow file... Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
rbj@dsys.icst.nbs.gov (Root Boy Jim) (04/04/89)
? From: Paul De Bra <debra@alice.uucp>
? Date: 5 Mar 89 16:50:28 GMT
? In article <199@tnl.UUCP> norstar@tnl.UUCP (Daniel Ray) writes:
? >Hello everybody. I am trying to hack together a working equivalent to
? >the /etc/shadow scheme of unreadable passwords. I run a XENIX 386 v2.2.3
? >system, and only have a binary license. Working with the 'bpatch' binary
? >editor, I was planning to substitute the word 'shadow' for 'passwd' in
? >the text string appearances of '/etc/passwd' in the compiled object files
? >for: /bin/passwd, /etc/login, and /bin/su. (Then I would have cron periodic-
? >ally copy /etc/shadow to /etc/passwd except that the 2nd field would be
? >an 'x' in the public /etc/passwd version, while the real passwd file would
? >be /etc/shadow).
? >...
? Wait a minute... this is not a useful way to implement /etc/shadow.
? The idea of /etc/shadow is to have a publicly accessible /etc/passwd that
? does not contain the (encrypted) passwords. /etc/shadow only contains the
? login and encrypted passwords (and possibly some other secret stuff).
? It is to prevent password hacking that the password should be in the
? unreadable file. I don't see much use for your copy of /etc/passwd.
? Maybe you want to reconsider the whole idea?
? Paul.
? --
? ------------------------------------------------------
? |debra@research.att.com | uunet!research!debra |
? ------------------------------------------------------
I disagree. Both files, /etc/passwd *and* /etc/shadow should look *exactly*
alike, except that the passwords in /etc/passwd should be random. Consider:
The Bad Guy is really, or rather looks like, a Good Guy. That is, he
has an account on your machine. So he changes his password, and sees
that /etc/passwd doesn't change, or that the entry remains `x'. You
have now alerted him to the fact that /etc/passwd is not the real
file, so he goes looking for the real one. The above reasoning applies
if he gets a copy of /etc/passwd somehow.
Perhaps the point is moot; the real security comes from the fact that
/etc/shadow is unreadable. However, one of the best ways to keep a
secret is not to let on that there is one. Often Bad Guys are quite
clever at one thing while totally missing another obvious point; I
can just see someone `successfully' cracking the fake password
file only to discover mysteriously that it doesn't work.
In any case, there are several solutions to the problem of changing
/etc/shadow to mode 400 instead of mode 444. The first is the
hard way; either use bpatch or adb or something else, find the
constant 444, and change it to 400. Another easier way is to
wrap /bin/passwd in another program that simply does a chmod
after the real /bin/passwd runs. This leaves a small window
where /etc/shadow could possibly be read however.
Catman Rshd <rbj@nav.icst.nbs.gov>
Author of "The Daemonic Versions"norstar@tnl.UUCP (Daniel Ray) (04/05/89)
In article <18939@adm.BRL.MIL>, rbj@dsys.icst.nbs.gov (Root Boy Jim) writes: > > I disagree. Both files, /etc/passwd *and* /etc/shadow should look *exactly* > alike, except that the passwords in /etc/passwd should be random. Consider: > > The Bad Guy is really, or rather looks like, a Good Guy. That is, he > has an account on your machine. So he changes his password, and sees > that /etc/passwd doesn't change, or that the entry remains `x'. You > have now alerted him to the fact that /etc/passwd is not the real > file, so he goes looking for the real one. The above reasoning applies > if he gets a copy of /etc/passwd somehow. A very good suggestion. I thought of it, but decided that it might be just too complicated simulating the encrypted keys, and when they are changed. Maybe I'll do this down the road, however. > ... > In any case, there are several solutions to the problem of changing > /etc/shadow to mode 400 instead of mode 444. The first is the > hard way; either use bpatch or adb or something else, find the > constant 444, and change it to 400. Another easier way is to > wrap /bin/passwd in another program that simply does a chmod > after the real /bin/passwd runs. This leaves a small window > where /etc/shadow could possibly be read however. I solved this by making the NEW real password file something like /dir/x/y/ze with the parent directories /dir/x/y being closed. No chmod necessary, *and* it prevents links to the file. > > Catman Rshd <rbj@nav.icst.nbs.gov> > Author of "The Daemonic Versions" I just got ahold of the excellent public domain /su/passwd/login clone programs from jfh@rpp386, so I have something new to play with as far as passwd goes. Fun fun! norstar The Northern Lights, Burlington Vermont | There *is* tnl dialins: 802-865-3614 at 300-2400 bps. ` | / no real security ------------------------------------------ --- * --- so lets uucp: uunet!uvm-gen!tnl!norstar or / | . PRETEND! {decvax,linus}!dartvax!uvm-gen!tnl!norstar |