Для чего нужно инициализированное поле в java.lang.SecurityManager? - PullRequest
Новая
       19

Для чего нужно инициализированное поле в java.lang.SecurityManager?

0 голосов
/ 01 июля 2018

В java.lang.SecurityManager есть логическое поле с именем initialized. 

public class SecurityManager {

    /*
     * Have we been initialized. Effective against finalizer attacks.
     */
    private boolean initialized = false;
    //some code
    /**
     * Constructs a new <code>SecurityManager</code>.
     *
     * <p> If there is a security manager already installed, this method first
     * calls the security manager's <code>checkPermission</code> method
     * with the <code>RuntimePermission("createSecurityManager")</code>
     * permission to ensure the calling thread has permission to create a new
     * security manager.
     * This may result in throwing a <code>SecurityException</code>.
     *
     * @exception  java.lang.SecurityException if a security manager already
     *             exists and its <code>checkPermission</code> method
     *             doesn't allow creation of a new security manager.
     * @see        java.lang.System#getSecurityManager()
     * @see        #checkPermission(java.security.Permission) checkPermission
     * @see java.lang.RuntimePermission
     */
    public SecurityManager() {
        synchronized(SecurityManager.class) {
            SecurityManager sm = System.getSecurityManager();
            if (sm != null) {
                // ask the currently installed security manager if we
                // can create a new one.
                sm.checkPermission(new RuntimePermission
                                   ("createSecurityManager"));
            }
            initialized = true;
        }
    }
    //some code
}

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

Я взял поиск в интернете о атаках финализатора . Я понял, что мы не должны зависеть от методов, которые могут быть переопределены ненадежным кодом. Но как это связано с инициализированным полем? Я все еще могу наследовать java.lang.SecurityManager, и если SecurityManager установлен, но доступ к закрытым полям с помощью отражения разрешен, инициализированное поле должно быть в состоянии редактировать. Так как же это эффективно против атак финализатора?

1 Ответ

0 голосов
/ 01 июля 2018

Это старая техника защиты: https://www.ibm.com/developerworks/java/library/j-fv/j-fv-pdf.pdf

В двух словах: атаки финализатора - это когда вы переопределяете метод finalize() объекта, который служит деструктором, который GC будет вызывать для освобождения собственных ресурсов. Но как только вы создадите подкласс или переопределите его с помощью отражения - инварианты / «обещания» исходного кода больше не будут выполняться.

Как избежать атаки

До третьего издания Спецификации языка Java (JLS) реализован в Java SE 6, единственный способ избежать атаки - использование initialized флаг, запрещающий создание подклассов или создание final финализатор - были неудовлетворительные решения.

Использование инициализированного флага:

Один из способов избежать атаки - использовать флаг initialized, который установите в значение true, как только объект был правильно создан. Каждый метод в класс сначала проверяет, установлена ​​ли initialized, и выдает исключение, если это не так. Этот вид кодирования утомительно писать, легко пропустить случайно, и не мешает атакующему создание подкласса метода.

...