发信人: bali()
整理人: williamlong(1999-12-13 19:10:00), 站内信件
|
发信人: [email protected] (邂逅), 信区: hacker
标 题: 网络安全(20)
发信站: cs3 BBS (Mon Jun 16 14:51:04 1997)
转信站: sjtubbs!sjtunews!cs3
Origin: 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: [email protected].]
--
大果子
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 202.97.225.207]
|
|