访问控制:Windows与Linux


12

我正在阅读MIT 6.893的演讲,该演讲Unix中的保护是一团糟,没有任何底层原理,并且还指出Windows 具有更好的替代方案,可以通过IPC将特权从一个进程传递到另一个进程

我认为,尽管Windows用户似乎更容易受到病毒和漏洞的攻击,但我认为这主要是由于大多数Windows用户经验不足的计算机用户,并且Windows平台拥有更多的用户,因此吸引了更多的攻击者。

我想知道是否有更详细的文章或论文比较Windows和Linux中的安全机制和设计?


1
好问题。多年来,我一直想知道* nix如何更安全,因为NT具有统一的基本安全性原理,以及在网络堆栈中从计算机级别扩展安全性的成熟方法。* nix仅具有用户帐户,文件安全性和网络安全子系统,这是事后才想到的。

4
Linux同时具有DAC和MAC。DAC是用户帐户,MAC是SELinux和AppArmor。
LiraNuna

让战斗开始;)
基督徒

3
安全既不会以访问控制开始也不会以访问控制结束。写下您所引用内容的人都是危险的狭narrow和/或无知的人。关于这个主题的字面上有数以百万计的文章,因此,只要您看一下就可以发现一些文章。
John Gardeniers'2

1
当然,这是一个有趣的问题,但是不幸的是,任何 Linux vs Windows主题都可能会产生烟火,因此我决定关闭。
Maximus Minimus

Answers:


2

没有人会怀疑在Windows上写缓冲区溢出比在Linux上难得多。同样,Windows中的ACL系统在很多方面都比* nix系统优越得多(仍然可以使用setpgid()打破chroot()/ jail()的范围并将伪根令牌传输到有效的UID 0 )。

然而。

Linux,BSD,Solaris和AIX具有用户制作的补丁的优点,这些补丁实现了非常出色的安全功能。我命名为PaX / GrSEC项目,无论过去几年中存在哪些安全缺陷,它都为实现地址空间布局随机化设定了标准,对于StackGuard,W ^ X以及旨在防止堆和格式化字符串攻击成功。严格地从访问角度来看,已经过时的当前系统有许多扩展。

如果工艺师的攻击是一个关心你,不要是古怪的Unix管理员,但Windows却遭遇更糟糕

简而言之,如果您懒惰,那么使用Windows更好。如果您比较勤快,那么使用* Nix常常会更好(从安全角度而言)


“没有人会怀疑在Windows上写缓冲区溢出比在Linux上难得多”?你是认真的吗?它是Windows软件错误的第一大原因,通常被用作攻击媒介。
约翰·加迪尼尔

2
实际上,我认为您最好利用自己最了解的知识,因为在您不熟悉的操作系统上错误配置安全性要容易得多(查看有关安全事件实际发生的百分比的统计信息很有趣,这很有趣。结果)。
Maximus Minimus

2
@John-程序上的意思是,在Linux中,您所需要做的就是劫持存储的EIP,使用getuid(setuid())包装器生成bash,在99.9%的非ASLR / StackGuarded情况下,您已经准备好了走。如果您曾经在Win32 / 64中编写过B0F,则您会注意到令牌问题,这些问题既琐碎又令人讨厌,并且经常破坏堆栈粉碎尝试,这是MS实现的其他保护机制。同样,AFAIK,近来,“免费使用后”在Microsoft应用程序中的使用要普遍得多(大概是因为/ GS开关)。含糊其辞。
ZV -

很高兴您能解释一下,因为这肯定不是我的阅读方式。
约翰·加迪尼尔

在Windows上写缓冲区溢出的原因更难,是因为在更高版本的Windows中,如此之多的应用程序对Bufferoveran进行了开发,而不是像unix(valgrind)那样免费发布工具来查找溢出,他们决定在每个内存周围放置无人区。分配以减少它击中某些关键内存的可能性。这就是Windows 10 + 7“似乎”可靠且“稳定”的原因。
猫头鹰

2

这是一篇详细的文章,它成为问题的核心–无关紧要的访问控制和安全系统有多强大……如果它太复杂以至于无法正确设置它们,您将面临安全漏洞。在这种情况下,系统的复杂性-“表面”越大,出现安全漏洞的机会就越大。

我以前在我们的域组中看到过这种情况-如果组太多,则很难使某人访问受保护的资源(如果他们位于错误的组中)。寄存器更好地描述了这一点


寄存器链接在允许/拒绝事项上存在一些实际的错误,但是否则这是一个有趣的观点。
Maximus Minimus

1

我想知道是否有更详细的文章或论文比较Windows和Linux中的安全机制和设计?

一个声音比较好,我的新手的眼睛...有点老略微偏,但没有这么多。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.