home *** CD-ROM | disk | FTP | other *** search
/ The World of Computer Software / World_Of_Computer_Software-02-385-Vol-1of3.iso / c / cops_104.zip / cops_104 / perl / README.kuang < prev    next >
Text File  |  1992-03-10  |  9KB  |  189 lines
  1. This is a perl version of Dan's version of Bob Baldwin's Kuang program
  2. (originally written as some shell scripts and C programs). 
  3.  
  4. The original intent was to improve the speed of kuang, which is
  5. especially important for installations like ours with several thousand
  6. accounts and NFS things and all that.  The shell version of Kuang used
  7. C programs to add rules, get a groups members, determine the writers
  8. of a file, and so on, which really slowed things down.
  9.  
  10.         "no" problems    /etc staff writeable
  11.         -------------    --------------------
  12. shell kuang    2:14 (14)    12:26 (98)    0.1 p/s
  13. perl kuang    1:10 (18)     2:34 (588)    3.8 p/s
  14.  
  15. --- Steve Romig, CIS, Ohio State, October 1990
  16.  
  17. ------------------------------------------------------------------------------
  18.  
  19. Some Features
  20. ---- --------
  21.  
  22.   Caches passwd/group file entries in an associative array for faster
  23.   lookups.  This is particularly helpful on insecure systems using YP
  24.   where password and group lookups are slow and you have to do alot of
  25.   them...:-)
  26.  
  27.   Can specify target (uid or gid) on command line.
  28.  
  29.   Can use -l option to generate PAT for a goal.
  30.  
  31.   Can use -f to preload file owner, group and mode info, which is
  32.   helpful in speeding things up and in avoiding file system
  33.   'shadows'...  See the man page for details.
  34.  
  35. Future plans, things to fix:
  36. ----------------------------
  37.  
  38. - In a large environment (like ours, 260+ machines, 30+ file systems
  39.   on as many servers, 2000 password file entries served by YP) it
  40.   would be nice to 'precompute' successful plans that would be common
  41.   to all systems.  In particular, plans for becoming most of the users
  42.   with home directories on the NFS file systems would be useful, since
  43.   we don't really want to recheck these on each host.  You wouldn't
  44.   want the plan to be too deep - probably shouldn't span more than 2
  45.   uids (1 on each end: grant u.romig grant g.staff write ~foo/.login
  46.   grant u.foo).  I'm thinking that you could feed a list of these
  47.   precomputed plans to kuang and add some code that causes it to
  48.   splice in relevent plans where it can to short cut the planning
  49.   steps.  For example, if one of the plans in uids.next is something
  50.   like "grant u.foo ...", and I have the precomputed plan mentioned
  51.   above, I could splice the two: "grant u.romig grant g.staff write
  52.   ~foo/.login grant u.foo ..." and skip all the normal steps that
  53.   would've been taken to get there.
  54.  
  55. - Hmmm...thinking about it, it seems like some of the steps are a bit
  56.   too implicit...maybe the rules should be broken out a bit more.
  57.   That will cost in processing time, though.
  58.  
  59. - Would be really, really nice to be able to deal with PATH variables
  60.   - location of ., who can write elements of path, etc.  Basic rule is
  61.   "anyone who can replace anything in any of path directories or the
  62.   path directories themselves can become that PATH's user..."  This
  63.   can be really messy though - in our environment, the path for a user
  64.   will depend on the architecture type of the machine that he is
  65.   logged into, and to get the path, you'd have to read and interpret
  66.   his .login (including variable assignments, source's and
  67.   conditionals).  Urf.  One wonders whether it might be better to have
  68.   something running as root that su's to each username in turn and
  69.   gets the path that way...
  70.  
  71. - ignore plans that start with "uid root", unless that's the only element - root
  72.   can get to anything, and hopefully nothing can get to root...?
  73.  
  74. - remove duplicate names from uid2names and gid2names...
  75.  
  76. - with ~/.login world writeable - only follows group path, but not OTHER.
  77.  
  78. - add plans to asseccible list.
  79.  
  80. Done
  81. ----
  82.  
  83. - Need to find all plans that lead to compromise, not just a plan.
  84.  
  85. - An earlier version scanned the password file looking for generally
  86.   accesible accounts (no password), which would be added to the
  87.   uids.known list (in addition to -1, "other").  I had planned on also
  88.   adding a password checker which would allow us to also add accounts
  89.   with easily guessed passwords.  Eventually I nuked the code that
  90.   scanned the password file to speed things up, and further reflection
  91.   reveals that it isn't wise to add the password scanning to kuang
  92.   itself.  At some point we should add a comand line option that
  93.   allows us to add additional uid's (or gid's?) to the uids.known
  94.   list.  That way the user could run some other tool to scan the
  95.   password file and generate a list of accessible accounts, which
  96.   could then be fed to kuang.  Makes it faster on clients using YP
  97.   since most of the password file is the same for all N clients, why
  98.   scan it N times.  Means that user can do smarter things to/with the
  99.   password file checks (list all accounts with no password or easily
  100.   guessed password, filter out "ok" entries (eg, sync) and etc.)
  101.  
  102. - We aren't dealing with uid's and gid's correctly.  If there are
  103.   several entries that list the same UID, but with different names,
  104.   directories and shells, we'll only check plans for becoming one of
  105.   them, rather than any of them.  Hmmm...this is easier than I
  106.   thought, when we evaluate some plan for granting a particular uid,
  107.   we need to evaluate plans for all usernames that can become that
  108.   uid.  Just stick a loop in there somewhere...get CF's for each of
  109.   username's in turn.  Bah, harder than I thought, since it'd have to
  110.   scan the whole password file to figure which username/home directories
  111.   can become which uid's.  Similarly with groups.
  112.  
  113.   Current plan: by default, kuang will have to scan the whole password
  114.   and group files so it can be sure to get all possible ways to become
  115.   some uid or gid.  Internally, really need several lists:
  116.  
  117.     mapping from uid to list of usernames that have that uid
  118.     mapping from a username to home directory, shell
  119.     mapping from gid to list of uids that have access to that
  120.       gid when they login (either member of group with that gid or
  121.       given as login group in passwd file)
  122.     mapping from gid to list of group names for that gid
  123.  
  124.   Course, this means that we have to read the whole password and group
  125.   file, most of which will be common to many machines (like in a YP
  126.   environment).  We could preload the tables above from files created
  127.   once, containing the brunt of the YP info, and then augment that
  128.   withthe local passwd and group info on each host when kuang is
  129.   invoked, but then we need to correctly interpret funky YP things
  130.   like +@netgroup:::*:..., which means that the uid has a name but no
  131.   password here...and similarly with shell substitutions and so on.
  132.   Bah. 
  133.  
  134. - The kuang described in Baldwin's dissertation is somewhat different
  135.   in nature from this one.  The original computes a Privilege Access
  136.   Table (PAT) which describes for each uid and gid which uids have
  137.   access to that uid.  To assess security, we compare this against the
  138.   security policy for the site, which similarly describes which uid's
  139.   are supposed to have access to each uid and gid.  A sample SP might
  140.   be that each uid should be accessible only by itself and root, and
  141.   each gid should be accessible only to the members of that group and
  142.   root.  If the PAT listed additional uid's for some priv, that would
  143.   constitute a violation of the Security Policy for the site.
  144.  
  145.   The current kuang is different.  It registers Success (a problem was
  146.   found) if it determines that some uid in the uids.known list (-1,
  147.   "other" by default) can access the target privilege.  It may find
  148.   along the way that extra uids can access some uid, but these aren't
  149.   reported as specific problems unless they are added to the
  150.   uids.known list. 
  151.  
  152.   We could do something similar to the kuang described in the paper by
  153.   setting uids.known to be all the uids that aren't in the security
  154.   policy table for the target uid, and running kuang against the
  155.   target.  This would report success for each uid that could access
  156.   the target.  You could do similar things with groups - uids.known
  157.   would be all the uids that aren't members of the group...
  158.  
  159.   Alternately, we could simply have kuang record the list of uids that
  160.   can access the target priv and print the list when its done.  That
  161.   way you could iterate kuang against all uids and gids and compare
  162.   the resulting PAT against your security policy and record the
  163.   differences.  You'd probably want to record the plan for each uid
  164.   reported also.
  165.  
  166.   On our system this would mean running kuang roughly 2500
  167.   times to check 1 host, and we have about 300 hosts...urf...assuming
  168.   that each kuang invocation has to check 50 plans, that's a total of
  169.   125,000 plans per host, or about an hour of real time...not as bad
  170.   as it could be, though.
  171.  
  172. - It would be nice to add to the list of rules.  It would be especialy
  173.   nice to extract the rules from the code so that we can create site
  174.   specific rule files (for example, we use X11r4 here, and many users
  175.   have a .Xinitrc that contains shell commands that get executed when
  176.   they login.)
  177.  
  178.   Easiest way to do this would be to extract the rules as Perl code so
  179.   we can take advantage of conditionals and so on, and include them
  180.   within the body of kuang somehow.  A sample rule in perl:
  181.  
  182.     if (&shell($uid) eq "/bin/csh") {
  183.         &addto("files", &home($uid)."/.login", 
  184.             "replace .login $plan");
  185.     }
  186.  
  187.   which simply means "if the user's shell is csh, then try to replace
  188.   his .login file." 
  189.