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