发信人: netman.bbs@cs3.xmu.edu.cn (邂逅), 信区: cnhacker
标  题: 网络安全(20)
发信站: cs3 BBS (Mon Jun 16 13:51:04 1997)
转信站: Lilac!ustcnews!ustcnews!sjtunews!cs3
出  处: cs3.xmu.edu.cn

  (11)启动和setuid程序引起的问题
      考虑这样的情况:计算机因发生某种事件后重新启动.这时机内保存的所
  有密钥都被清除,如果采用的是DES鉴别系统,那么所有的进程都不能再利用网
  络服务.这时起关键作用的是根进程.如果根的密钥保存在机内同时没有人输
  入口令,对该密钥进行编码,那么根进程就将能够利用网络服务.对以上问题的
  答案就是将根的密钥存放在关键字服务器可读的某个文件中.这样的方式对有
  盘工作站来说是很好的,但对无盘工作站来说,即存在一个致命的问题:它的密
  钥必须通过网络存取.这样在无盘工作站启动时,如有人窃听网络传送内容,他
  就能发现编码后的密钥,尽管完成,但这一工作并不容易.
      众所周知有一种启动方式叫单用户启动,启动后根的登录shell出现在主
  终端上,这儿出现的问题是,如果安装了C2安全系统,从单用户启动仍需口令;
  当没有安装C2安全系统时,只要/etc/ttytab文件中的console项标记为secure,
  机器的启动就不需口令.
      另一个问题是无盘工作站启动不安全,因为有人可以冒充启动服务器,启
  动一个不正当的内核记录远程无盘工作站的密钥,因为仅仅在内核和关键字服
  务器运行之后,SUN系统才能对这一问题提供保护.在此以前没有任何方式可以
  鉴别回答是否来自正确的启动服务器.但我们不考虑这种情况,因为一个不知
  道源码的人,要想写这样的内核几乎是不可能的.另外犯罪者也极易留下证据,
  只要你对网络中的启动服务器进行检测,就能发现谁是服务器.
      并不是所有的setuid程序都会按我们希望的那样运行,比如一个由用户
  dave拥有的setuid程序,只要在机器启动后,dave没有进行登录,那么程序
  setuid就不能存取安全的网络服务(即采用DES鉴别系统的网络服务),好在绝
  大多数setuid程序都为root所拥有,而且根的密钥在系统忘却后总是存放在系
  统中,因而程序setuid在采用了DES系统之后,仍能象原来那样运行.

  (12)总结
      SUN的目标是要让网络系统象分时系统一样安全,这个目标已经达到.在分
  时系统中,用户被口令鉴别,有个DES鉴别系统,网络中的用户也由口令鉴别.在
  分时系统中,用户信任系统管理员,他的职业道德不允许他改变用户的口令以
  冒充该用户.在SUN系统中用户信息网络管理员,他不会改变用户在公共密钥数
  据库中的实体.很,SUN的系统从某种意义上说比系统更安全,因为在SUN的系统
  中旋转"窃听"装置来"窃听"网络中传送的口令和编码用的密钥是无用的(因为
  这些口令和密钥都已被编码).而大多数分时系统对来自终端的数据并不进行
  编码,用户必须相信,没有人在终端与主机的传送线上安装"窃听"装置.
      DES鉴别系统也许不是最终完善的鉴别系统,在将来,很可能有更好的算法
  和硬件来证明DES鉴别系统无用并放弃它.但至少可以说DES为将来的发展指出
  了一个方向.从理论上讲,协议从来规定会话密钥甚至公共密钥的编码要采用
  Diff3-Hellman方法.为了使DES鉴别系统更有力,我们要做的仅仅是使会话密
  钥的编码更有力,从理论上说这样会形成另一个协议,但是RPC的优点在于它可
  以采用任何鉴别系统而本身不会受到影响.
      至少在目前我们可以说DES鉴别系统满足了我们对网络服务的安全要求,
  在一个不友好的网络系统中建立起了一个足够安全的系统,而所付出的代价也
  不高.用户不需使用磁卡或记住上百位的数字,用户像往常一样使用口令鉴别
  自己,只是系统的性能略有降低.但是如果用户认为性能降低不可并且他的网
  络系统非常友好的话,他可以不采用DES鉴别系统.

--
※ 来源:·古庙钟声 cs3.xmu.edu.cn·[FROM: freedom@cs3.xmu.edu.]