Inspired by a much more specific question on ServerFault.
受到ServerFault上更具体问题的启发。
We all have to trust a huge number of people for the security and integrity of the systems we use every day. Here I'm thinking of all the authors of all the code running on your server or PC, and everyone involved in designing and building the hardware. This is mitigated by reputation and, where source is available, peer review.
我们所有人都必须相信大量人员,以确保我们每天使用的系统的安全性和完整性。在这里,我想到了服务器或PC上运行的所有代码的所有作者,以及参与设计和构建硬件的每个人。这可以通过声誉得到缓解,并且在可用来源的情
Someone else you might have to trust, who is mentioned far less often, is the person who previously had root on a system. Your predecessor as system administrator at work. Or for home users, that nice Linux-savvy friend who configured your system for you. The previous owner of your phone (can you really trust the Factory Reset button?)
你可能不得不信任的另一个人,那些被提及得更少的人,就是以前在系统上有过根的人。您的前任是系统管理员。或者对于家庭用户来说,那个为您配置系统的精通Linux的朋友。您手机的前任所有者(您真的可以信任出厂重置按钮吗?)
You have to trust them because there are so many ways to retain root despite the incoming admin's best efforts, and those are only the ones I could think of in a few minutes. Anyone who has ever had root on a system could have left all kinds of crazy backdoors, and your only real recourse under any Linux-based system I've seen is to reinstall your OS and all code that could ever run with any kind of privilege. Say, mount /home with noexec and reinstall everything else. Even that's not sufficient if any user whose data remains may ever gain privilege or influence a privileged user in sufficient detail (think shell aliases and other malicious configuration). Persistence of privilege is not a new problem.
你必须相信他们,因为尽管管理员做了最好的努力,仍然有很多方法可以保留root用户,而这些只是我几分钟内能想到的。任何曾经拥有系统根源的人都可能留下各种疯狂的后门,而你在任何基于Linux的系统下唯一真正的追索权就是重新安装你的操作系统和所有可能以任何特权运行的代码。比如说,mount / home with noexec并重新安装其他所有内容。即使这样,如果任何数据仍然存在的用户可能获得特权或足够详细地影响特权用户(想想shell别名和其他恶意配置),那就不够了。持久性特权不是一个新问题。
How would you design a Linux-based system on which the highest level of privileged access can provably be revoked without a total reinstall? Alternatively, what system like that already exists? Alternatively, why is the creation of such a system logically impossible?
您如何设计一个基于Linux的系统,在没有完全重新安装的情况下,可以证明*别的特权访问可以被撤销?或者,这样的系统已经存在?或者,为什么创建这样一个系统在逻辑上是不可能的?
When I say Linux-based, I mean something that can run as much software that runs on Linux today as possible, with as few modifications to that software as possible. Physical access has traditionally meant game over because of things like keyloggers which can transmit, but suppose the hardware is sufficiently inspectable / tamper-evident to make ongoing access by that route sufficiently difficult, just because I (and the users of SO?) find the software aspects of this problem more interesting. :-) You might also assume the existence of a BIOS that can be provably reflashed known-good, or which can't be flashed at all.
当我说基于Linux时,我的意思是可以运行尽可能多的软件,尽可能在Linux上运行,尽可能少修改该软件。物理访问传统上意味着游戏结束,因为键盘记录器可以传输,但假设硬件足够可检查/防篡改,使得该路由的持续访问足够困难,仅仅因为我(以及SO的用户?)找到了这个问题的软件方面更有趣。 :-)您可能还会假设BIOS的存在可以被证明重新已知 - 良好,或根本不能闪现。
I'm aware of the very basics of SELinux, and I don't think it's much help here, but I've never actually used it: feel free to explain how I'm wrong.
我知道SELinux的基础知识,我认为这不是很有帮助,但我从来没有真正使用过它:随意解释我的错误。
2 个解决方案
#1
First and foremost, you did say design :) My answer will contain references to stuff that you can use right now, but some of it is not yet stable enough for production. My answer will also contain allusions to stuff that would need to be written.
首先,你确实说设计:)我的答案将包含你现在可以使用的东西的引用,但其中一些还不够稳定,不适合生产。我的回答还将包含对需要编写的内容的暗示。
You can not accomplish this unless you (as user9876 pointed out) fully and completely trust the individual or company that did the initial installation. If you can't trust this, your problem is infinitely recursive.
除非您(如user9876指出)完全和完全信任进行初始安装的个人或公司,否则您无法实现此目的。如果您不能相信这一点,那么您的问题将无限递归。
I was very active in a new file system several years ago called ext3cow, a copy on write version of ext3. Snapshots were cheap and 100% immutable, the port from Linux 2.4 to 2.6 broke and abandoned the ability to modify or delete files in the past.
几年前我在一个名为ext3cow的新文件系统中非常活跃,这是ext3的写版本。快照很便宜且100%不可变,从Linux 2.4到2.6的端口破坏并放弃了过去修改或删除文件的能力。
Pound for pound, it was as efficient as ext3. Sure, that's nothing to write home about, but it was (and for a large part) still is the production standard FS.
磅为英镑,它与ext3一样高效。当然,没什么好写的,但它(并且很大一部分)仍然是生产标准FS。
Using that type of file system, assuming a snapshot was made of the pristine installation after all services had been installed and configured, it would be quite easy to diff an entire volume to see what changed and when.
使用这种类型的文件系统,假设在安装和配置所有服务之后快照是由原始安装完成的,那么很容易区分整个卷以查看更改的内容和时间。
At this point, after going through the diff, you can decide that nothing is interesting and just change the root password, or you can go inspect things that seem a little odd.
在这一点上,在完成差异之后,您可以确定没有任何有趣的东西,只需更改root密码,或者您可以去检查看起来有点奇怪的事情。
Now, for the stuff that has to be written if something interesting is found:
现在,如果找到有趣的东西,必须写的东西:
- Something that you can pipe the diff though that investigates each file. What you're going to see is a list of revisions per file, at which time they would have to be recursively compared. I.e. , present against former-present, former-present against past1, past1 against past2, etc , until you reach the original file or the point that it no longer exists. Doing this by hand would seriously suck. Also, you need to identify files that were never versioned to begin with.
- Something to inspect your currently running kernel. If someone has tainted VFS, none of this is going to work, CoW file systems use temporal inodes to access files in the past. I know a lot of enterprise customers who modify the kernel quite a bit, up to and including modules, VMM and VFS. This may not be such an easy task - comparing against 'pristine' may not be tenable since the old admin may have made good modifications to the kernel since it was installed.
- Databases are a special headache, since they change typically each second or more, including the user table. That's going to need to be checked manually, unless you come up with something that can check to be sure that nothing is strange, such a tool would be very specific to your setup. Classic UNIX 'root' is not your only concern here.
你可以通过调查每个文件来管理差异的东西。您将看到的是每个文件的修订列表,此时必须对它们进行递归比较。即,针对前现在,前任现在对抗过去1,过去对抗过去2等,直到你到达原始文件或它不再存在的点。用手做这件事会非常糟糕。此外,您需要识别从未开始版本化的文件。
检查当前运行的内核的东西。如果有人污染了VFS,那么这些都不会起作用,CoW文件系统使用时间inode来访问过去的文件。我知道很多企业客户对内核进行了相当多的修改,包括模块,VMM和VFS。这可能不是一件容易的事 - 与'pristine'进行比较可能不成立,因为旧的管理员可能已经对内核进行了很好的修改,因为它已经安装好了。
数据库是一个特别令人头疼的问题,因为它们通常每秒或更长时间更改一次,包括用户表。这需要手动检查,除非你想出一些可以检查以确保没有任何奇怪的东西,这样的工具将非常特定于你的设置。经典的UNIX“root”不是你唯一关注的问题。
Now, consider the other computers on the network. How many of them are running an OS that is known to be easily exploited and bot infested? Even if your server is clean, what if this guy joins #foo on irc and starts an attack on your servers via your own LAN? Most people will click links that a co-worker sends, especially if its a juicy blog entry about the company .. social engineering is very easy if you're doing it from the inside.
现在,考虑网络上的其他计算机。他们中有多少人正在运行一个已知容易被利用并被机器人出版的操作系统?即使你的服务器是干净的,如果这个人在irc上加入#foo并通过你自己的局域网开始攻击服务器怎么办?大多数人会点击同事发送的链接,特别是如果它是一个关于公司的多汁的博客文章。如果你从内部进行社交工程很容易。
In short, what you suggest is tenable, however I'm dubious that most companies could enforce best practices needed for it to work when needed. If the end result is that you find a BOFH in your work force and need to can him, you had better of contained him throughout his employment.
简而言之,您所建议的是可行的,但是我怀疑大多数公司可以在需要时执行所需的最佳实践。如果最终的结果是你在工作中找到了一个BOFH并且需要他,那么你最好在他的工作中遏制他。
I'll update this answer more as I continue to think about it. Its a very interesting topic. What I've posted so far are my own collected thoughts on the same.
当我继续思考它时,我会更新这个答案。这是一个非常有趣的话题。到目前为止我发布的内容是我自己收集的相同想法。
Edit:
Yes, I know about virtual machines and checkpointing, a solution assuming that brings on a whole new level of recursion. Did the (now departed) admin have direct root access to the privileged domain or storage server? Probably, yes, which is why I'm not considering it for the purposes of this question.
是的,我知道虚拟机和检查点,这个解决方案假设它带来了一个全新的递归级别。 (现已离职)管理员是否具有对特权域或存储服务器的直接root权限?可能是的,这就是为什么我不考虑这个问题的原因。
#2
Look at Trusted Computing. The general idea is that the BIOS loads the bootloader, then hashes it and sends that hash to a special chip. The bootloader then hashes the OS kernel, which in turn hashes all the kernel-mode drivers. You can then ask the chip whether all the hashes were as expected.
看看可信计算。一般的想法是BIOS加载引导加载程序,然后散列它并将该散列发送到特殊芯片。然后,引导加载程序对操作系统内核进行哈希处理,从而对所有内核模式驱动程序进行哈希处理。然后,您可以询问芯片是否所有散列都符合预期。
Assuming you trust the person who originally installed and configured the system, this would enable you to prove that your OS hasn't had a rootkit installed by any of the later sysadmins. You could then manually run a hash over all the files on the system (since there is no rootkit the values will be accurate) and compare these against a list provided by the original installer. Any changed files will have to be checked carefully (e.g. /etc/passwd will have changed due to new users being legitimately added).
假设您信任最初安装和配置系统的人员,这将使您能够证明您的操作系统没有任何后续系统管理员安装rootkit。然后,您可以手动对系统上的所有文件运行哈希(因为没有rootkit,值将是准确的),并将它们与原始安装程序提供的列表进行比较。必须仔细检查任何已更改的文件(例如,由于合法添加新用户,/ etc / passwd将发生更改)。
I have no idea how you'd handle patching such a system without breaking the chain of trust.
我不知道如何在不破坏信任链的情况下处理修补这样的系统。
Also, note that your old sysadmin should be assumed to know any password typed into that system by any user, and to have unencrypted copies of any private key used on that system by any user. So it's time to change all your passwords.
另请注意,应假设您的旧系统管理员知道任何用户在该系统中键入的任何密码,并且任何用户都要在该系统上使用任何私钥的未加密副本。所以是时候更改所有密码了。
#1
First and foremost, you did say design :) My answer will contain references to stuff that you can use right now, but some of it is not yet stable enough for production. My answer will also contain allusions to stuff that would need to be written.
首先,你确实说设计:)我的答案将包含你现在可以使用的东西的引用,但其中一些还不够稳定,不适合生产。我的回答还将包含对需要编写的内容的暗示。
You can not accomplish this unless you (as user9876 pointed out) fully and completely trust the individual or company that did the initial installation. If you can't trust this, your problem is infinitely recursive.
除非您(如user9876指出)完全和完全信任进行初始安装的个人或公司,否则您无法实现此目的。如果您不能相信这一点,那么您的问题将无限递归。
I was very active in a new file system several years ago called ext3cow, a copy on write version of ext3. Snapshots were cheap and 100% immutable, the port from Linux 2.4 to 2.6 broke and abandoned the ability to modify or delete files in the past.
几年前我在一个名为ext3cow的新文件系统中非常活跃,这是ext3的写版本。快照很便宜且100%不可变,从Linux 2.4到2.6的端口破坏并放弃了过去修改或删除文件的能力。
Pound for pound, it was as efficient as ext3. Sure, that's nothing to write home about, but it was (and for a large part) still is the production standard FS.
磅为英镑,它与ext3一样高效。当然,没什么好写的,但它(并且很大一部分)仍然是生产标准FS。
Using that type of file system, assuming a snapshot was made of the pristine installation after all services had been installed and configured, it would be quite easy to diff an entire volume to see what changed and when.
使用这种类型的文件系统,假设在安装和配置所有服务之后快照是由原始安装完成的,那么很容易区分整个卷以查看更改的内容和时间。
At this point, after going through the diff, you can decide that nothing is interesting and just change the root password, or you can go inspect things that seem a little odd.
在这一点上,在完成差异之后,您可以确定没有任何有趣的东西,只需更改root密码,或者您可以去检查看起来有点奇怪的事情。
Now, for the stuff that has to be written if something interesting is found:
现在,如果找到有趣的东西,必须写的东西:
- Something that you can pipe the diff though that investigates each file. What you're going to see is a list of revisions per file, at which time they would have to be recursively compared. I.e. , present against former-present, former-present against past1, past1 against past2, etc , until you reach the original file or the point that it no longer exists. Doing this by hand would seriously suck. Also, you need to identify files that were never versioned to begin with.
- Something to inspect your currently running kernel. If someone has tainted VFS, none of this is going to work, CoW file systems use temporal inodes to access files in the past. I know a lot of enterprise customers who modify the kernel quite a bit, up to and including modules, VMM and VFS. This may not be such an easy task - comparing against 'pristine' may not be tenable since the old admin may have made good modifications to the kernel since it was installed.
- Databases are a special headache, since they change typically each second or more, including the user table. That's going to need to be checked manually, unless you come up with something that can check to be sure that nothing is strange, such a tool would be very specific to your setup. Classic UNIX 'root' is not your only concern here.
你可以通过调查每个文件来管理差异的东西。您将看到的是每个文件的修订列表,此时必须对它们进行递归比较。即,针对前现在,前任现在对抗过去1,过去对抗过去2等,直到你到达原始文件或它不再存在的点。用手做这件事会非常糟糕。此外,您需要识别从未开始版本化的文件。
检查当前运行的内核的东西。如果有人污染了VFS,那么这些都不会起作用,CoW文件系统使用时间inode来访问过去的文件。我知道很多企业客户对内核进行了相当多的修改,包括模块,VMM和VFS。这可能不是一件容易的事 - 与'pristine'进行比较可能不成立,因为旧的管理员可能已经对内核进行了很好的修改,因为它已经安装好了。
数据库是一个特别令人头疼的问题,因为它们通常每秒或更长时间更改一次,包括用户表。这需要手动检查,除非你想出一些可以检查以确保没有任何奇怪的东西,这样的工具将非常特定于你的设置。经典的UNIX“root”不是你唯一关注的问题。
Now, consider the other computers on the network. How many of them are running an OS that is known to be easily exploited and bot infested? Even if your server is clean, what if this guy joins #foo on irc and starts an attack on your servers via your own LAN? Most people will click links that a co-worker sends, especially if its a juicy blog entry about the company .. social engineering is very easy if you're doing it from the inside.
现在,考虑网络上的其他计算机。他们中有多少人正在运行一个已知容易被利用并被机器人出版的操作系统?即使你的服务器是干净的,如果这个人在irc上加入#foo并通过你自己的局域网开始攻击服务器怎么办?大多数人会点击同事发送的链接,特别是如果它是一个关于公司的多汁的博客文章。如果你从内部进行社交工程很容易。
In short, what you suggest is tenable, however I'm dubious that most companies could enforce best practices needed for it to work when needed. If the end result is that you find a BOFH in your work force and need to can him, you had better of contained him throughout his employment.
简而言之,您所建议的是可行的,但是我怀疑大多数公司可以在需要时执行所需的最佳实践。如果最终的结果是你在工作中找到了一个BOFH并且需要他,那么你最好在他的工作中遏制他。
I'll update this answer more as I continue to think about it. Its a very interesting topic. What I've posted so far are my own collected thoughts on the same.
当我继续思考它时,我会更新这个答案。这是一个非常有趣的话题。到目前为止我发布的内容是我自己收集的相同想法。
Edit:
Yes, I know about virtual machines and checkpointing, a solution assuming that brings on a whole new level of recursion. Did the (now departed) admin have direct root access to the privileged domain or storage server? Probably, yes, which is why I'm not considering it for the purposes of this question.
是的,我知道虚拟机和检查点,这个解决方案假设它带来了一个全新的递归级别。 (现已离职)管理员是否具有对特权域或存储服务器的直接root权限?可能是的,这就是为什么我不考虑这个问题的原因。
#2
Look at Trusted Computing. The general idea is that the BIOS loads the bootloader, then hashes it and sends that hash to a special chip. The bootloader then hashes the OS kernel, which in turn hashes all the kernel-mode drivers. You can then ask the chip whether all the hashes were as expected.
看看可信计算。一般的想法是BIOS加载引导加载程序,然后散列它并将该散列发送到特殊芯片。然后,引导加载程序对操作系统内核进行哈希处理,从而对所有内核模式驱动程序进行哈希处理。然后,您可以询问芯片是否所有散列都符合预期。
Assuming you trust the person who originally installed and configured the system, this would enable you to prove that your OS hasn't had a rootkit installed by any of the later sysadmins. You could then manually run a hash over all the files on the system (since there is no rootkit the values will be accurate) and compare these against a list provided by the original installer. Any changed files will have to be checked carefully (e.g. /etc/passwd will have changed due to new users being legitimately added).
假设您信任最初安装和配置系统的人员,这将使您能够证明您的操作系统没有任何后续系统管理员安装rootkit。然后,您可以手动对系统上的所有文件运行哈希(因为没有rootkit,值将是准确的),并将它们与原始安装程序提供的列表进行比较。必须仔细检查任何已更改的文件(例如,由于合法添加新用户,/ etc / passwd将发生更改)。
I have no idea how you'd handle patching such a system without breaking the chain of trust.
我不知道如何在不破坏信任链的情况下处理修补这样的系统。
Also, note that your old sysadmin should be assumed to know any password typed into that system by any user, and to have unencrypted copies of any private key used on that system by any user. So it's time to change all your passwords.
另请注意,应假设您的旧系统管理员知道任何用户在该系统中键入的任何密码,并且任何用户都要在该系统上使用任何私钥的未加密副本。所以是时候更改所有密码了。