gnupasswd Files

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 !