你需要的比较简单：你需要确保你的学生的非特权账户被很好地限制。如果您没有涉及图形环境，那么您的情况相对简单。您应该首先执行以下操作：

• 确保创建用户时没有管理权限（no sudo、noadmin或wheelgroup）
• 确保用户无法模拟登录屏幕来欺骗您的登录屏幕（大学的经典，我见过发生）
• 确保适当的polkitd策略防止用户挂起/关闭主机
• 确保您不在主机上运行易受攻击/过时suid/服务（请参阅如何列出它们）sgid
• 确保没有单个用户可以耗尽系统的资源（通过配置Systemd.cgroup对每个用户的整个会话施加资源使用限制）
• 通过正确安装和配置SELinux 来加强您的强制访问控制（将学生限制为只能在家中和 /tmp 中写入的学生角色）
• 必要时使帐户过期，以避免使用最终泄露的密码的挥之不去的帐户（请参阅 Unix 站点上的此问题）
• 您甚至可以使用Systemd.nspawn在单独的容器中运行学生的会话，该容器旨在使用Linux 命名空间相互独立地运行完全正常工作的系统。这是监禁会话的正确方法，而不是chroot

然后，您可能会注意到学生将机器用于其他用途，而不是允许的用途。您可以将使用机器的访问权限限制在特定时间，pam_time但这可能会妨碍学生完成工作，并且应该与它提供的好处相平衡。此外，请确保您的网络管理员知道该主机上的预期流量，以便他们能够检测到不需要的流量。

综上所述，我没有看到将特定二进制文件列入白名单的意义（因为学生可以编译和运行自己的代码，所以它可能会妨碍学生使用合法的开发工具，例如替代编译器、构建工具链、代码分析工具、代码版本控制工具等。

只要用户只能伤害自己并且您对此有强有力的保证，那么工作就完成了。无论如何，这并不是一个长期的生产系统，学生们只是用它来玩弄教育代码。

它远未完成，但我大学的一群队友正在开发Mumuki。英文版 好像坏掉了，暂时没有英文内容，不过你可以在那里读到它的意图。您还可以加入该项目并使其运行 C++（我从 C 开始）。

该平台的想法是创建带有检查它们的单元测试的练习。

我们已经开始考虑如何以孤立的方式运行代码，但到目前为止还没有实现。

是的，有。首先，使用 SSH 并不是一个坏主意，但为了提高安全性，您可以执行以下操作：

• 使用 chroot jails 将所有通过 SSH 登录的“学生”用户锁定在受限环境中。
• 不要给他们 sudo 访问权限，而是使用 sudoers 列表中的特定脚本/命令来允许管理命令的有限子集。
• 使服务器不能在任何大于 1024 的端口上公开访问。（在高端口号上运行 ssh 以防止脚本小子访问）。
• 当您使用它时，鼓励他们使用 ssh 密钥登录。从安全角度来看，这些密钥远优于用户名/密码访问（前提是使用密码加密）。
• 作为替代方案，您可以为此使用 git 和持续集成。（例如 Gitlab 和 Jenkins 组合）这具有额外的好处，即只能通过安全的 Web 环境授予他们访问权限（当您使用 TLS 设置时，例如“https”，请使用适当的证书！）并且所有访问权限都是可审计的。

是的，还有其他方法。但是，我认为您的问题是基于有缺陷的假设。虽然允许更多人登录 shell 显然会产生安全影响，但这并不一定意味着最终系统的安全性无法得到有效管理。这些系统被设计为多用户系统，并且能够以不会危及安全性的方式管理此访问（或至少将风险级别管理到可接受的程度）。这些环境中的真正挑战是您通常没有资源来执行此操作。例如，单个学生档案不太可能就足够了——您需要档案来反映不同的需求。入门编程课程可能不会 不需要与网络编程或系统编程课程相同的访问权限。那么问题就变成了有足够的时间来管理所有这些不同的配置文件并确保它们是适当的。

说了这么多，我确实认为在这个时代，有一些替代方法可能更易于管理和更合适。例如，使用虚拟机可以非常高效。这些可以设置为使每个学生彼此隔离，并且可以这样做，以便他们可以将他们的虚拟环境“刷新”到已知的“良好状态”。还有一些基于 Docker 或 Vagrant 之类的解决方案，可用于让学生在自己的机器上创建标准且一致的环境。您的服务器不再是学生登录以完成工作的平台，而是成为一种分发机制，允许学生下载他们可以自己运行的工作环境。