Безопасность доступа к коду - это шутка?

Question

Я только что прочитал об этой статье о безопасности доступа к коду. В нем есть такой пример:

using System.Security.Permissions;
public class MyFileAccessor 
{
  public MyFileAccessor(String path, bool readOnly)
  {
    path = MakeFullPath(path); // helper fcn
    FileIOPermissionAccess desiredAccess = readOnly
      ? FileIOPermissionAccess.Read
      : FileIOPermissionAccess.AllAccess;
    FileIOPermission p = new FileIOPermission(desiredAccess, path);
    p.Demand();
    // 
    ••• 
    open the file
   }
   // •••
}

Что если я не использовал тип FileIOPermissionAccess и никогда не включал в свой код код типа p.Demand()? Другими словами, если я хочу сделать что-то плохое, зачем мне спрашивать разрешение на это? Разве это не шутка? ИЛИ Я правильно понял?

Answer 1

Ну, да, пример немного шутка, вы никогда не написали бы что-то подобное себе. Чего не хватает, так это действительно важной части, кода, который // открывает файл. Реалистичная версия, скажем, будет вызывать CreateFile().

Дело в том, что Windows ничего не знает о CAS. Поэтому, если вы предоставляете служебную функцию, подобную этой, и хотите применить правила CAS, вам необходимо убедиться, что у вашего вызывающего кода есть необходимые разрешения. Конечно, этот вид кода действительно принадлежит только.NET Framework. Посмотрите на FileStream.Init() и обратите внимание, что FileIOPermission там требуется перед вызовом CreateFile.

Answer 2

Доступ к файлу (например, с помощью FileStream) будет автоматически требовать FileIOPermission, И это так для всех стандартных классов, когда они выполняют какое-либо действие, требующее разрешения, они запрашивают его автоматически. Посмотрите под.NET Framework Security здесь. Так что пример кода бесполезен, никто явно не будет требовать разрешения для файла. Разумно, если вы разрабатываете некоторый API и ваш код подписан, чтобы никто не мог его изменить.

Читайте дальше, вот цитата из этой статьи:

Теперь в реальном мире вы не будете писать классы, такие как MyFileAccessor, для доступа к файлам. Вместо этого вы будете использовать предоставляемые системой классы, такие как System.IO.FileStream, которые уже разработаны для выполнения соответствующих проверок безопасности. Они часто выполняются в конструкторе со всеми последствиями для производительности и безопасности, которые я обсуждал ранее.

Answer 3

Внутри API java.io вы можете убедиться, что проверки выполняются. Если вы хотите контролировать доступ (обходя сбой до того, как он произойдет), вы должны сделать соответствующие проверки ДО внутренних проверок, выполненных вызовами API.

Java-код часто запускается на компьютерах, которые вы контролируете, но он также часто работает на компьютерах, которые вы не контролируете. Подумайте о Java-апплетах. Они должны запросить разрешение на доступ к файловой системе, потому что автору программы не следует разрешать доступ к файловой системе всех остальных.

Если вам нужно помешать одной группе людей совершить что-то вредоносное, вам нужно помешать всем, возможно, сделать что-то вредоносное, чтобы безопасность была реальной. В противном случае злоумышленники просто скажут, что они являются частью группы, которой не доверяют.

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

То, что вы видите, является доказательством того, что не существует специальной задней двери, которая обходит безопасность для некоторых пользователей (или в некоторых условиях).