home *** CD-ROM | disk | FTP | other *** search
/ Hacker Chronicles 1 / HACKER1.ISO / cud2 / cud209g.txt < prev    next >
Text File  |  1992-09-26  |  11KB  |  205 lines
  1. ------------------------------
  2.  
  3. Subject: The Ultimate Interface: Hackers and the Private Sector
  4. From: Dark Adept
  5. Date: Tue, 23 Oct 90 22:19 CDT
  6.  
  7. ********************************************************************
  8. ***  CuD #2.09: File 7 of 8: Hackers and the Private Sector      ***
  9. ********************************************************************
  10.  
  11.           The Ultimate Interface:  Hackers and The Private Sector
  12.  
  13. A major problem in Cyberspace is the lack of communication between hackers
  14. and non-hackers.  Corporations are fully entitled to their privacy, and so
  15. they feel threatened by the hacker "menace."  They view the hacker as the
  16. enemy, and so they persecute him. This is a valid belief since history
  17. shows that when a group does not understand another group, they try to
  18. destroy it.  Saying this is valid does not make it right.  If hackers and
  19. corporations and security companies and software companies, etc., etc.,
  20. etc. were to overcome their differences much could be done.  By trading
  21. bits and pieces of knowledge, the two opposing groups could together
  22. develop revolutionary advances in computing that would benefit all.  The
  23. problem is to get the two groups to trust one another.  In some upcoming
  24. G-Philes and submissions to CuD, I hope to break down this barrier of
  25. resentment by crossing over the lines of the Underground into the "real"
  26. world and providing valuable information about systems, security,
  27. interfacing, etc. from a hacker's/member-of-the-underground's point of
  28. view.  I hope others will follow suit, and that the private sector will
  29. reciprocate by allowing technical information to flow into the Underground.
  30. Ultimately, I hope that there will be a rapport between hackers and members
  31. of the private sector so that we may learn from each other and make the
  32. best use possible of this greatest of inventions, the computer.  Without
  33. further delay, then, I present the first of what I hope will be a long and
  34. successful series of articles.  These must be short since they are merely
  35. articles, but I have planned a few full-length works that will be more
  36. in-depth; I will send them to the CuD archives as they become available.  I
  37. hope you enjoy them.
  38. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  39.  
  40.             System Security:  Security Levels and Partitioning
  41.  
  42.                              by The Dark Adept
  43.  
  44. Traditionally, security levels are used to prevent a user from gaining
  45. access to areas where he lacked legitimate interest.  They also have
  46. another very useful purpose that is seldom recognized.  They can be used as
  47. a firewall of sorts to stop the spread of viruses and the destruction of
  48. files by an intruder.  A good analogy of this theory is ship design.  When
  49. a ship is designed, the lower compartments are designed separate from each
  50. other so that if the hull is punctured, the flooding compartment may be
  51. sealed off thus localizing the damage and stopping the ship from sinking.
  52. In the same way accounts should be assigned security levels.  However, if
  53. the accounts are fully isolated from one another, it is too restrictive to
  54. be of any real use.  A user in Accounting would not be able to access the
  55. records from Personnel to find an employee's rate of pay, for example.
  56. Optimally, then, one would want a balance between freedom and security.
  57. This optimal assignment of security levels is accomplished through a
  58. two-stage step.
  59.  
  60. The first stage is the creation of generic accounts.  Many computer
  61. systems, such as those of schools, use generic accounts as their sole
  62. source of security.  This is VERY dangerous.  By generic accounts, I mean a
  63. set of basic accounts where each member has certain privileges assigned to
  64. it that differ from the other members.  For example, in schools the
  65. teachers often receive one type of account, and students another.  Besides
  66. the systems operator's account, these are the only two types of accounts
  67. available.  The teachers have a wide-range of freedoms including being able
  68. to look into files that don't belong to their department since they can be
  69. trusted. The students have a limited amount of ability, mostly restricted
  70. to accessing their files only.  But what happens if an intruder grabs a
  71. teacher's account?  You got it, he has access to A LOT of stuff!
  72. Obviously, this won't do.  However, generic accounts are useful if used in
  73. combination with other devices.  This leads to the implementation of the
  74. second stage: security levels.
  75.  
  76. Example:  Let X, Y, and Z be generic accounts in system S with the
  77. following maximum abilities:
  78.  
  79. X can access file areas A, B, C, D
  80. Y can access file areas B, D, J, K
  81. Z can access file areas B, C, J, L
  82.  
  83. Assume some User, u, needs access to file areas B and L alone.  Assign him
  84. account type Z with security modifications such that he may access only
  85. file areas B and L.
  86.  
  87. This results in User u being restricted to the proper file areas, B and L,
  88. but allows ease of modification later if he needs access to areas C or J.
  89. It also allows for the greatest amount of security since his account type
  90. is Z so by definition he cannot access file areas A, D, or K without
  91. receiving a new account.  Therefore, if an intruder takes control of
  92. account u, he cannot destroy more than areas B and L without modification.
  93. The most he can modify account u to have access to is areas B, C, J, and L.
  94. Therefore the damage will be localized to file areas B, C, J, and L.  The
  95. only way he can enter the other areas is to get a new account. This is much
  96. more difficult than modifying one he already has.
  97.  
  98. The same sort of setup may be applied to commands, usage times, dialup
  99. ports, etc.  For example, say the editor of a newspaper has account Z that
  100. has maximum port capability of T, t1, t2, t3 where T is a terminal in his
  101. office and t1, t2, and t3 are outside lines.  At first he is assigned a
  102. security level that allows access to T only so his account cannot be
  103. accessed from intruders outside thus stopping someone from deleting all of
  104. tomorrow's edition.  Now, if he must go on location somewhere, it would be
  105. a simple matter to modify his account to give him access to t1 so he can
  106. call up and review the submissions.  Yet, again, if there exist ports t4,
  107. t5, etc., these would NEVER be able to access the files since account type
  108. Z is incapable of being accessed through these ports.
  109.  
  110. What follows here is a mathematical model of account partitioning using
  111. concepts of discrete mathematics.  Since this is a text file and cannot use
  112. graphics characters, some common mathematical symbols must be defined using
  113. regular characters.
  114.  
  115. Symbols:
  116. --------
  117.  
  118. |    = "such that" (ordinarily a vertical bar)
  119. \e\  = "is an element of"  (ordinarily an emphasized epsilon)
  120. <==> = "if and only if"
  121.  
  122. Model:
  123. -----
  124.  
  125. Let S represent a computer system.
  126.  
  127. Let S1 be a set of different areas of interest in a computer system.  This
  128. is modelled by S1={a1,a2,a3,...,an} where n is some integer, and a1,a2,
  129. a3,... are the areas of interest in S.
  130.  
  131. Let S2 be a set of different user accounts in a computer system.  This is
  132. modelled by S2={u1,u2,u3,...,uq} where q is some integer, and u1,u2,
  133. u3,... are the user accounts in S.
  134.  
  135. Let x \e\ S2.  Let y \e\ S1. Let r be a relation on S defined as this:
  136.  
  137. xry <==>  x \e\ S2 | x has access to y.
  138.  
  139. Now r becomes a partitioning relation on S2.  The function that defines r
  140. is determined by how the operator wants his accounts set up.
  141.  
  142. Further, the equivalence class of x, [x], defines the generic account.
  143.  
  144. Example: Say S has accounts u1, and u2.  It also has areas of interest a1,
  145. a2,a3.  Now say the operator wants u1 to have access to a1 and a2, and u2 to
  146. have access to a1 and a3.  By defining r in the proper manner he gets:
  147. r ={(u1,a1), (u1,a2), (u2,a1), (u2,a3)}.  Now [u1]={a1, a2} and
  148. [u2] = {a2, a3}.  Thereby defining the generic accounts.
  149.  
  150. Now let G be the set of all of the equivalence classes determined by xry
  151. that define generic accounts in S.  This is seen as G={[x]|x /e/ S2}.
  152.  
  153. For clarity, let g1 = [u1], g2 = [u2], ... so we have G={g1,g2,...gq} where
  154. q is some integer.
  155.  
  156. Now let d \e\ G.  We define w to be a relation as such:
  157.  
  158. dwy <==> d \e\ G | d has access to y.
  159.  
  160. Now w becomes a partitioning relation on G.  The function that defines w
  161. is determined by how the operator wants to implement a generic account
  162. for a particular user.
  163.  
  164. Further, the equivalence class of d, [d], defines the specific user
  165. account.
  166.  
  167. Example:  Say S has generic account g1 set up.  It has areas of interest
  168. a1, a2, and a3.  g1 is partitioned in such a way that it can only access a1
  169. and a3.  Now say the operator wants a certain holder of a generic account
  170. type g1 to have access only to a1.  By defining w in the proper manner he
  171. obtains: w={(g1,a1)}.  Now [g1]={a1} thereby defining an appropriate user
  172. account.
  173.  
  174. As some may have noticed, accounts can be partitioned ad infinitum.  In
  175. most cases I have found two partitions to be sufficient.  An interesting
  176. adaptation is also to use this method to define what users have access to
  177. which commands.  It again allows much room for change while keeping things
  178. safely separate.
  179.  
  180. The ultimate safety would come when the first partition is defined in the
  181. operating/timesharing system itself.  For example, if Unix (Tm of AT&T)
  182. came with say 30 different file areas and accounts accessing those areas in
  183. specialized ways, then even if an intruder grabbed the root account, he
  184. could not change the first level of partitioning to access all those
  185. accounts.
  186.  
  187. As I hope I have shown, the proper use of generic accounts and security
  188. levels allows the optimum balance of security and ability.  By properly
  189. partitioning accounts, the system operator can isolate a problem to a
  190. relatively small area allowing faster restructuring afterward.
  191.  
  192. I hope you have enjoyed this article.  I can be reached for comments,
  193. criticism, and E-mail bombs at Ripco BBS (312)-528-5020.  Also, if you
  194. liked this article, you may comment to Jim Thomas (editor of CuD) and he
  195. can pass the general reception on to me.
  196.  
  197. Written 10/21/90 in Chicago, IL -- The Dark Adept
  198.  
  199. ********************************************************************
  200.                            >> END OF THIS FILE <<
  201. ***************************************************************************
  202.  
  203.  
  204. Downloaded From P-80 International Information Systems 304-744-2253 12yrs+
  205.