0

我是 JAAS 的新手，但我仍然无法得到一件事：如果恶意用户手动创建主题和主体怎么办？

如果用户篡改它，不应该对主题/委托人进行一些验证吗？我见过的教程都没有提到这一点。

看看这个例子（来自 jaasbook.com 的 ch02）：

SimpleCallbackHandler cb = new SimpleCallbackHandler(username,
    password);
LoginContext ctx = new LoginContext("chp02", cb);
ctx.login();
Subject subject = ctx.getSubject();
System.out.println("Logged in " + subject);
Subject.doAsPrivileged(subject, new PrivilegedAction() { ...

如果我用这个代码替换这个代码：

Subject subject = new Subject();
Principal p = new SysAdminPrincipal(username);
subject.getPrincipals().add(p);
Subject.doAsPrivileged(subject, new PrivilegedAction() { ...

它也同样有效（至少在这个示例代码中）。

我一定错过了一些明显的东西，否则使用 jaas 根本没有意义。谢谢

4

1 回答 1

0

区别在于可信代码和不可信代码。

如果您允许代码在您不信任的 JVM 中运行，那么您需要使用配置的策略来保护 JVM，并在启用 SecurityManager 的情况下运行。这类似于 Java Applet 环境。在这样的环境中，您通常会锁定部分代码库，以便只有来自受信任来源的代码，以及可选的加密签名，才能运行或调用代码的其他部分。

在 Java 安全性中，当进行权限检查时，会检查整个调用堆栈以确保允许堆栈的每个部分使用权限。

在这种情况下，您将启动一个将 Subject 与 AccessControlContext 相关联的 PrivilegedAction。如果您查看源代码，您会看到执行权限检查：

javax.security.auth.AuthPermission "doAs";

在默认的 Java 安全策略中，唯一可以执行此操作的代码是已安装的 Java 扩展，因此如果您想在自己的代码中执行此操作，并使用正在运行的 SecurityManager，您将需要手动设置此权限。

因此，Subject 类是不受保护的，因为除非它与 AccesssControlContext 关联，否则它没有任何影响。

AccesssControlContext 受 AuthPermission 保护。

AuthPermission 的设置受 JVM 启动时配置的 security Policy 和 SecurityManager 保护。

在这种情况下，如果您在没有 SecurityManager 的情况下运行，或者没有向任何代码库授予 AllPermission 的自定义策略，并且您允许运行不受信任的代码，那么您就会遇到很大的安全问题。

如果您想运行不受信任的代码并将主题分配给 AccessControlContexts，则保护执行此操作的代码将类似于以下策略文件：

grant codebase "file://home/me/myapp.jar" signedby "me" {
    javax.security.auth.AuthPermission "doAs";
}

这可以保护只有您的代码库（包括调用堆栈）才能执行主题分配。

或者只是确保您信任部署到应用程序的代码……这是 99% 的部署方案，大多数应用程序在其宿主环境中受到保护，并且不允许执行远程代码。

于 2013-03-31T14:32:51.257 回答