Предоставляет ли AccessController.doPrivileged потокам JavaScript разрешения подписанного апплета?

Question

Я смотрю на подписанный апплет, который часто вызывается из JavaScript. Очевидно, что потоки, происходящие из JavaScript, более сильно изолированы, чем любой поток, запущенный непосредственно из Java. Например, если поток JavaScript вызывает апплет и регистрирует что-то, что вызывает откат файла журнала, выдается исключение безопасности. Любой поток, запущенный непосредственно в апплете, не столкнется с этим исключением безопасности. Решение с помощью log4j заключается в использовании асинхронного приложения.

Но с другими исключениями безопасности (например, с использованием Apache Axis в подписанном апплете, но в потоке JavaScript) не существует очевидного способа создания некоторого асинхронного потока. Допустим, у меня есть следующий код, который при вызове из потока Java будет работать, а при вызове через JavaScript произойдет сбой с SecurityException:

public void someMethodCalledFromJavaScript() {
  // Stuff that would throw a SecurityException
}

Я вижу три следующих варианта, но они не все могут быть действительными. Ради этого обсуждения проигнорируйте, будет ли выполнение синхронным или асинхронным, поскольку это легко управляется. Мне сложно понять детали модели безопасности. Вот мои три возможных варианта:

• Создать новую тему (сработает ли эта?):

  public void someMethodCalledFromJavaScript() {
    new Thread(new Runnable() {
      public void run() {
        // Stuff that would throw a SecurityException
      }
    }).start();
  }
  

• У апплета должен быть готовый к работе поток, запускаемый через поток JavaScript-источника (очень упрощенный код здесь):

  private volatile boolean doit = false;
  
  // This code is running in a Thread, started @ Applet init time
  public void alwaysWaiting() {
    while (true) {
      if (doit) {
        doit = false;
        // Stuff that would throw a SecurityException
      }
    }
  }
  
  public void someMethodCalledFromJavaScript() {
    doit = true;
  }
  

• Использовать AccessController.doPrivileged:

  public void someMethodCalledFromJavaScript() {
    AccessController.doPrivileged(new PrivilegedAction() {
      public Object run() {
        // Stuff that would throw a SecurityException
        return null;
      }
    });
  }
  

Согласно тому, что я прочитал о AccessController.doPrivileged, вы работаете с пересечением текущих привилегий безопасности и привилегий области безопасности кода, который вы вызываете. Это не имеет смысла для меня, так как если вы работаете с пересечением домена с низким и высоким уровнем безопасности, у вас просто будет домен с низким уровнем безопасности. Ясно, что я чего-то не понимаю.

Конкретный SecurityException Я вижу вот что:

java.security.AccessControlException: access denied (java.lang.RuntimePermission accessDeclaredMembers)

но, конечно, меня интересует общий случай в контексте вызова JavaScript в подписанный апплет и как я могу позволить потоку из JavaScript запускаться с priv-ом подписанного апплета, как если бы он был потоком которая возникла исключительно в апплете.

Какие варианты выбора выше будут работать, а какие лучше, чем другие, и почему.

Answer 1

• "Создать новую тему (будет ли эта работа вообще работать?)"

Не работает по причинам, указанным ниже

• Пусть апплет всегда готов к запуску потока, запускаемого через нить JavaScript-источника

Конечно, будет работать, но это более болезненно, чем вызов doPrivileged, но семантически имеет тот же эффект.

• Использовать AccessController.doPrivileged

Да, это будет работать.

Каждая проверка контроля доступа проверяет набор всех кадров стека в стеке текущего потока (включая кадр стека, приводящий к созданию экземпляра текущего потока, рекурсивно). Если есть кадр doPrivileged, кадры, ведущие к этому кадру, не включаются в набор (но фактический doPrivileged кадр включает в комплекте).

Если проверяемая привилегия присутствует не в каждом отдельном кадре в этом наборе, проверка не пройдена.

Другими словами, текущие привилегии потока являются пересечением привилегий в этом наборе.

Так, например, если в привилегированном коде doPrivileged есть какой-то непривилегированный код, который пытается открыть файл, проверка не будет выполнена. Аналогично, если непривилегированный код doPrivileged является привилегированным кодом, открывающим файл, проверка не будет выполнена. Но если непривилегированный код вызывает привилегированный код, а привилегированный код, в свою очередь, вызывает doPrivileged, чтобы открыть файл, проверка пройдет успешно.

Теоретически, вы должны иметь возможность предоставлять только вашей кодовой базе Java необходимые ей привилегии (возможно, доступ к некоторому изолированному каталогу), а затем предоставлять такие же привилегии JavaScript код, который будет использовать этот привилегированный код, но я сомневаюсь, что любой браузер имеет такие функции. Я удивлен, что JavaScript работает даже в другом домене защиты, чем Java.

Я никогда не делал JavaScript <-> взаимодействие с Java, но, кажется, неважно, что вам нужно, чтобы методы, вызываемые JavaScript, использовали блоки doPrivileged во всем своем теле.

---

РЕДАКТИРОВАТЬ: Как сказал Сами, будьте осторожны при вызове doPrivileged блоков в привилегированном коде (и прочитайте его ответ).

Answer 2

Я бы пошел с doPrivileged.Просто имейте в виду, что каждый, кто имеет доступ к вашему апплету, может загрузить его и разместить на своем сайте, а его собственный вредоносный javascript вызывает его так, как вы не представляли.

Последствия для безопасности других решенийв значительной степени то же самое (РЕДАКТИРОВАТЬ: хотя создание новой Темы не работает, как указывал Longpoke), но они более сложны.Поэтому я не вижу никаких преимуществ с ними.

AccessController.doPrivileged рассматривает домен защиты только непосредственного абонента.В вашем примере класс, в котором определен ваш метод someMethodCalledFromJavaScript.Если это доверенный класс в подписанном фляге, не имеет значения, что его вызывает ненадежный Javascript.