Wed Aug 12 11:49:55 EDT 2015
SECTIONS
INSTALL
SUMMARY
FEATURES
NEW passwd.x
NOTES
CONFIGURATION
HISTORY
MIGRATION
SECURITY
TESTING login.c
------------------
INSTALL
make
make install BINDIR=/usr/local/bin
chmod +s /usr/local/bin/passwd
# +s after deciding you like it
# for Makefile.gnu, BINDIR has default
# pmake so set BINDIR, and early pmake set MANDIR and MAN1
------------------
SUMMARY of gnupasswd
/*
* FILE: gnupasswd.c
* DESC: objective is a passwd(1) which supports only older linux styles:
* old gnu libc format (crypt and shadowing are optional)
* ie, old meaning that /etc/passwd is supported with or without crypt
* ie, old meaning ONLY password change is supported (for all else, vi?)
* NEW: -X uses /etc/passwd.x for real passwords (unlike /etc/shadow,
* passwd and passwd.x are same excepting for the passwords
* NOTE: any of the above require login.c understand resulting format
* use is for older/simpler /etc/password and login.c
* NOTE: /etc/nsswitch.conf, if db or nis, might ignore some /etc/passwd
* (/etc/passwd is still sourced when maps are rebuilt by servers)
*/
------------------
FEATURES
gnupasswd ony edits the password field, it leaves all other fields alone.
gnupasswd offers root ways to tailor password for some given login.c
gnupasswd -E testing passwd styles without clobbering real passwd files.
-o salt -c -S -X -W -E -T -P -U -A -e
gnupasswd supports older/simpler usage of /etc/passwd and shadow.
gnupasswd supports using /etc/password, /etc/password.x, /etc/shadow as REAL
password file. (as opposed to public readable password file: see HISTORY)
(ie, plain passwords in /etc/passwd only login.c can read, but see HISTORY)
gnupasswd is small and has easy to follow MAC source code:
no nis, selinux, pam, kerb, remote audit, crypt optional
gnupasswd checks / sets uid, euid, and file perms when needed
ie, if real passwd is world readable: it quits rather than offering help
gnupasswd sets signals so /etc/passwd is not left 1/2 written ctrl-c
gnupasswd always does error checking and memory clearing
(changes are written only after batch succeeds)
gnupasswd locks passwd file for batch write (glibc does lock for read)
* other apps get right file busysignal rather than some random error
* with goal of acceptable stability (rather than security paranoia)
gnupasswd can compile and work without crypt, shadow, fgetpwnet - it should
work with any Unix and if hacked can even work without getpwent
extra info (like expiry) does not "need to be" in a passwd file
(infact, root could use gecos field in orig. or any file, si vu plea)
caveat or bonus? no minimum password length is enforced, and no grand
dictionary or formulator of password is included
(on a simple system: vi and awk can do things except: offer passwd well)
(be nice if a struct editor or db editor could be configured for pwd file
that supports typical pwd crypt and "safe" and not bloated: not heard of it!)
(caveate? gnupasswd does NOT check istty like some very recent do - though
login always had checked these. gpasswd assumes only group owner can
change group pass and so must be a real user, else only root can)
caveate: gnupasswd is new (2015) and is not thoroughly tested in general
--------------------
NEW passwd.x
if you use passwd.x (having edited login.c to check for it) you can use
(plain) crypt or even plaint text passwords: as safely as unix had been before
distros began forcing software to publicly read /etc/passwd file down the pipe
concept: it's the orig /etc/passwd file except non-public
it's used only by login.c, if you didn't know
a benefit is having both file the same (password aside) and not
having to manage extra info or ramification of them on running system
but see notes: /etc/passwd still is authoritive for passwd.x or shadow
(Comparing -X to shadow, shadow does not use gecos instead has whole added
format and requires a special login.c to do something with the info: also
note that info may be ignored if using ldap, pam, kerb which aren't
necessarily shadow compat. Also: shadow uses crypt a little differntly than
old linux passwd did. One might add some info shadow added has no need
to be in passwd file at all (site admin can do same without relying on
login.c to support it))
see HISTORY: fake /etc/passwd is opposite of what most suggested at the time!
(rather than public supplemental info file, as ftp et al already were using)
--------------------
NOTES
most options are "root only" since they would allow the malicious
room to damage
-o salt -S -c -X -W -E -T -P -U -A
-X use passwd.x as non-public /etc/passwd (same fmt but with real pass)
note: /etc/passwd still is authoritive for :: :*: and :x:
where :x: means use shadow or passwd.x, -S is automatic
salt is not supposed to be seen ever, see below
-A all means output file without any changes
-e edit. it'd be too complex (more buggy) if users could edit
any field (could damage files trash input). thus this option
allows avoiding vi(1), for root only.
-T use fprintf or putpwent (usu. for compat with non-glibc2)
if fgetpwent isnt compiled in, internal can be used to allow -X
pwd_search() and grp_search() which do the "same' as fgetpwent
"by hand" which are not thoroughly tested but present and do work
(with that, gnupasswd is ready to extend format in or out)
if /etc/passwd.x /etc/shadow exist, then /etc/passwd is considered
to be chmod 0644 "not where passwords are". this has effects using
certain options. if you intend to use /etc/passwd as real passwd, then
remove the other two from /etc/ (for sake of login.c too i imagine)
Note for passwd.x or shadow that it's the new
tradition that /etc/passwd, if it contains :: (no pass required) or :*:
(no pass matches) that is authoritive (check login.c to be sure), and that
/etc/passwd contains :x: to authorize (passwd.x or shadow) to contain
the real passwords PER user, conferred by login.c specifically.
-> this allows, libc/nis to operate independant of site login.c, su, passwd
That being so changes to /etc/passwd are not allow by normal users (if
shadow passwd.x exist). why is, say root set "::" for guests, then any one
guest may set passwd locking out all guests? if root has "*" that means NO
(end of story: if root makes info public: private users should not edit)
Given the above: if /etc/passwd is PUBLIC, root should use vi(1) to edit it,
and bother not with -e in most all cases, or use -Z if you did. on a small
site having a "specialized suite to do it" is unecessary, and chfn chsh
(small utils hacked from older unix could be used, likely are breakable
now, so careful)
gnupasswd does NOT enforce min. passwd len or prevent "common names"
feel free to add that in at your site if you dont allow :: logins
HOWEVER! use a passwd >8 chars and make sure it appears to be random
letters and numbers ("crack" cannot tell if it cracked this way unless
it were to use login (which would take ostensibly forever, due to sleep 3)
putpwent always writes to temp file passwd.tmp then to whichever is the
real passwd file after that's done successfully
getpwent is the default when possible, depending on settings
(ie, getpwent does not see shadow or passwd.x, fgetpwent can)
fgetpwent is used elsewise, but internal for -W.
/etc/passwd is never written unless it has the real passwords
this can be changed with commandline options
usually salt is generated, not provided
salt can be used to so that decryption fails except by random attempt, but
it is usually only used to widen the crypt string (easy to see because
$salt$ is easily identified as a stored salt string) (meaning it is still
important that no one but login.c be able to read /etc/passwd.x,shadow)
(gnupassword uses crypt how shadow does)
salt can change encryption options however gnupasswd only allows root to
supply it (making sure salt it is clean supported and allowed is beyond the
parsing gnupasswd scope; dirty salt undermines any benefit of salt). the
default is to generate salt that works with login.c and /etc/shadodow
non-root users are not allowed to provide "user" they are looked up by id
a note to shadow users: only "user" is supported, id is assume from
/etc/passwd (see next paragraph)
a note to shadow users: uid gid in public /etc/passwd is authoritive
and must match /etc/shadow (using passwd.x only passwd.x is heeded),
but for gpasswd getlogin (if uid is also group owner) uses /etc/passwd
important: in all cases the first entry for 'name' found is taken
as the authoritive one - and the concept of having two entries of
same name is assumed erroneous and to be removed
important: 'nobody' having no home is assume to be able to acceess in /tmp/
-W for -X if fgetpwent isnt compiled in and internal pwd_search is
avoided, root can use system(pivot files) which goes before/after
getpwent putpwent are done so they "work" (this was coded
before pwd_search was had)
-> dont use it, likely
MAC (see below) with passwd.x alone is secure unless admin goofs and leaves
.x readable (assuming it is made using advisable unix perms as always)
Until networking an cleartext pass over wire is in the picture: in which
case crypt is also insufficient (see openssl below). Insuff. but most
modems crypt internet traffic, so cleartex is more a LAN problem.
MAC works because hardware supports it (but see below) and because it
is too simple to fail (except by human error!)
As for networking NIS should never be able to alter pass below uid 100,
and by definition all user accounts are not too secure. How to
insure it "has no bugs" i cant say it's too complex. Add remote
"security" by pam seliux audit (note audit is NOT quota from AT&T unix)
and esp when allowing dbus (configured by who?) to run: i cant say it's
way too complex: and there is the problem.
group passwords are infrequently used by today's admins, its very
"common" for groups to be real users and group passwd being "*"
(Never matched)
--------------------
CONFIGURATION
$ chmod 0644 /etc/passwd # any that are public
$ chmod 0644 /etc/group # any that are public
$ chmod 0640 /etc/shadow # default for linux
$ chmod 0640 /etc/gshadow # default for linux
$ chmod 0400 /etc/passwd.x # whichever is real (passwd.x, passwd, shadow)
$ chmod 0400 /etc/group.x # whichever is real (passwd.x, passwd, shadow)
$ chmod +s gnupasswd
shadow is default if present, -X is optional
(and login.c must be hacked to see or prefer)
NOTE: if /etc/passwd is holds real passwords, it is 0400 and remove passwd.x
and shadow from /etc. as far as passwd.x v. shadow, that is up to login.c
if both are present, gnupassword does not create them though
1) users cannot see passwords file ever (0400, maybe 0640)
1a) users never know salt (preferrably salt is never in any file)
2) without -c, if a malicious user does see password file it must first
be processed to reveal usable plain text passwords
HOWEVER this is not to hard - especially because salt
is typically stored in file - which it shouldnt be?
(most all login.c expect to see and use it, so by default it is)
(typically, unix admin would option only specific terminals
can log in at all, semi trusted ones in /etc/securetty,usertty
depending on login.c)
Poor as it may be on 1-10 scale, default unix security (MAC, mandatory
access control, ie 0400, password checked) with added passwd.x/shadow file
offering obscurity, suffice for most interests
If this is insufficient, openssl offers alternate authentication but does not
have getpwent() and crypt() so passwd and login.c would need to be altered.
? trying to use /etc/passwd as real passwd file?
CHECK LOGIN.C can read your passwd file before
loggin out or rebooting !!
BUT WAIT why wouldn't it your login is hacked work ?
since '93 or before they all used (the same) crypt. they used to
check for plain text pass but many now dont (fixing is easy though)
** you might want to do this jic (this works for changing login too)
in inittab have this:
1:2345:respawn:/sbin/getty -l /bin/login [opts] 38400 tty1
2:23:respawn:/sbin/getty -l /bin/newlogin [opts] 38400 tty2
( could also run w/o -a , use >>, mv file when done, or output just passwd
and fiddle with file that way )
--------------------
DISCUSSION
password can bet set suid (see chown(1)) which allows a program running as
root to be ran by a normal user. in older unix only a very few programs
that ran as root users accessed: login.c, passwd.c (mail submission
possibly, though there were endless problems with) (getty.c which invokes
login.c is not setuid, no user is logged in)
passwd allows users to enter only one "allowable" item (prevents them from
doing anything other than doing the one allowed thing, which might allow
mischief)
otherwise only the (kernel or X11) (hardware drivers) that allow user to use
hardware (disk, video, audio) run as root like getty.c does (not setuid)
these do specified tasks some of which only root can do (maybe user can save
files but not mount certain devices). users shoudl have access only to drivers
specially tuned allow only safe actions (such as writing plain text to a plain
text area of one's own screen)
because todays software expects /etc/passwd to be public it must not have
passwords in it (even though that was it's purpose see history), so a separate
file with real passwords not world readable is maintained (/etc/shadow or
/etc/passwd.x).
(NIS allows remote control of passwds above uid 100 - meaning the computer is
meant for anybody (even attackers) to be able to log in to perform limit
actions (use certain software running as limited user). this is fine if the
computer is meant to be public access, if yp binaries are not broken
by linux default nis is in /etc/nsswitch.conf but not active w/o yp binaries)
(shadow passwd(1) may contact remote computers and share authentication or
offer elevated access to remote parties while being used - problem is it is
so complex one cannot be sure without reading all code)
why does passwd.c 0 memory? this is for sites who have either malicious users
or when users run highly questionable web software. what happens is the kernel
(ie, linux) pools memory and has no concept of reserving memory only to be used
by 'root'. when root uses (vi) to edit passwords and exits, the memory held
displaying passwords goes back to the pool. now lets say user runs mozilla
and automatically it updates. these updates are well known to "phone home"
meaning they contact remote computers and transmit information they can obtain
back to a malicious remote user. because linux gave memory to web browser
(for efficiency, it is not cleared first) the malicious program can transmit
all it's program memory back to remote comuter: which may contain about
anything). as well if "java", php, mysql, or mozilla is not secure also
the app can transmit all user files to the malicious party - who is probably
sifting for BANKING INFORMATION)
now note if root sees passwords that video cards do not have MAC
which means though passwd.c cleared cpu memory - likely nothing cleared the
video memory, and the video card does not check user id (a similar issue
exists with lan/wifi hardware, audio hardware, non-scsi motherboards)
MAC also note that security is out the window if hardware is removed and
mounted as a slave drive (for that one would need drive encryption, which is
weak (again, openssl) and can cause total data loss due to bugs - which is
usually worse than a (small) chance of data getting browsed)
this is why i advise people to use (a laptop) for web browsing with
anticipation it is not secure and all upon it will be seen / stolen
now you might say: well 'root' can write anywhere on disk. no. even modern
linux (is said to) not allow any MAC breaches
$ su root
$ chown root:root file
$ chmod ugoa-w file
root is now denied access to change file until chmod is run
but another part of mac (see SECURITY) is simply setting the MAC bits so
the hardware does not have race conditions or allow bad softare to effect
certain parts of memory...
HISTORY
today one runs apps they havent read the code for (written
by "foreigners") run as root they can do anything hu-
man, they have *more* ability than a human to gain root
access and dont ever need a passwd. *thats* why
huge "passwd suites" are rediculous (for open wares).
early 90's many apps claimed they needed username thus
needed to read passwd, it was a lie then and many in
the day said so. ie, USER, LOGNAME. also: easily a
file having only users names world readable could be
allowed, or a file in user's home having USERNAME
could have been used, ~/USERNAME. all rediculous
as no hastle is every really needed: was all hype
to get access to passwd to viruses in that day.
also note in the 90's everyone that anyone interested
in protecting passwd is also, or moreso, interested
in protecting user name. in otherwords 'finger'
was allowed in-house only and was one of few well
known apps allowed to read /etc/passwd
furthermore, from what i understand of "shadow.h"
the default allows any root program to still open, read
write to /etc/shadown (chmod 640). it would be better
to force apps to chmod to read it, chmod 000, which
makes more obvious when a "real effort" was made to read.
worse - shadow adds "expiry" but not BSD compat and that
then begs all linux code to be a hack different
MIGRATION
the "general issue" of passwd db incompatibility applies to all OS
and is continually a problem for those who "migrate"
at times distros have fiddled with making passwd db incompat even
between similar distros to twist an arm (to force use of their OS)
or to offer a way in but not a way out
ex: distro-A uses "ftp:pass:96", distro-B uses "ftp-data:x:97"
now all files on your disk have wrong user ID ! OUCH !!
it can be tricky solving the problem unless you only upgrade
and only using their prescription
another reason, ie they drop say uucp support then if you install uucp
pk the first available UID is used; never asking checking if you have
uucp files already (they dont): you need migration (they dont)
i have not found any good password migration tools. few exist and are
not for linux. i wrote one but it is NOT perfect , but worked for me.
it only works for migrating UID and only with the well know GNU / BSD
style /etc/passwd (noting GNU BSD while similar require migrating)
see also:
http://sourceforge.net/projects/gmil/files/from-unix-dbootstrap-install.tar.gz
which contains a script function that migrates passwd UID from old to new
(it does UID slot mapping) AND changes all files to reflect changes
(you can rip the function out, it's for programmers only, good luck)
(it works unless you run out of slots from being near user # limit)
SECURITY
cpu security was for preventing buggy software from overheating glass
tube transistors. it was not meant to be safe from humans. login
is not security from police, telephone company, the kernel, many things
NEVER ASSUME your PC is secure dont put anything on it you cant afford
to have others see
it's better to make passwd NOT suid and allow only admin to run it
users can submit requests by leaving a file which only they root can read
(allowing root to avoid unecessary suid bins - which if even interrupted
could say, leave 1/2 a file written at a bad time - suid is not perfect)
------------------
TESTING login.c
one can back up old login binary then install gnupasswd, change a passwd with
it, then just try 'rsh' or switch to a terminal asking for login. but
be prepared if it denies login so you can restore login and or files
- ie incase you accidentally get power out or logged out.
testing a change to /etc/passwd is easy (backup passwd file, use gnupasswd
to edit one user entry - only that entry is effected, restore passwd if not,
and of course -E option allows working in test directory)
the same thing goes if testing an altered login.c to see if that works: Always
provide an alternate to old one incase the new doesn't work!
careful: running login from sh prompt probably will log you OUT
(your then at mercy if untested login/passwd will work)
* try /sbin/getty 38400 tty9 -l /bin/login BEFORE rebooting
! make sure you can login or will get at least maintenance prompt !
* edit /etc/inittab to give yourself a shell if login fails
(temporary, until your sure all is well)
4:23:respawn:/sbin/getty -l /bin/login 38400 tty6
5:23:respawn:/sbin/getty -l /usr/local1/bin/login.new 38400 tty6
6:23:respawn:/sbin/getty -l /usr/local1/bin/login.know_good 38400 tty6
# run this to tell init(1) to re-read your edits
$ telinit Q
* edit /etc/rc.S (runs single user, see inittab) and give yourself
a way in (carefully) insuring you get a shell if "locked out"
------------------
developer notes
if you hack bit to allow user to supply name it is later ignored
in general check carefully if allowing user to do anything excluded
since it likely involves providing code to make it safe or even supported
User should be restricted to supply only one item Password, using libc.
Any other "input" would have to be similarly be carefully checked for
memory over-runs and sanity as to passwd checking but libc as well.
Being setuid: any input from user can allow a malicious error finding
in the code to become a possible root access. The code should do
one safe thing and not be deterred to do elsewise, and
be un-complex as possible.
why not hack in a way to edit gecos? in which? passwd.x or real?
what is chmod? getpw had constructed "proper" entry from string but
is now unsupported - one has no way good way to get input (even getpass
is diminished but not replaced either). so there is no way to know
what "will not break glibc" - let alone other libc (ie, wouldnt have
HAVE_FGETPWENT if not unix other-libc minded). so to allow a user
the privelage to hack in a string they might know breaks something in
a setuid binary: exactly what setuid is meant not to be. hopefully
i followed my own advice!
point is: to "fix all that" would be more hacking
and a hopefully small uncomplex binary shoudl be -
even grp passwd was made separate for that reason
anyhow, adduser is supposed to be a whole diff program (or use vi)
which only root runs and polls for each item n.i. checked password
- totally different gig. you can del user then add while they are
logged in, no harm done - a per field tool like chfn or finger "are extras"
allowing extra file (passwd.x or shadow) introduced quite more complexity
than i had planned for (3 read/write methods for unix compat too) its
already too complicated (should be trimmed not improved) as far as i see it
------------------
License GPL/2
------------------
THANK YOU
happy hacking !