Безопасность доступа к коду - это шутка? - PullRequest
Новая
       15

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

7 голосов
/ 18 октября 2010

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

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 () вмой код вообще?Другими словами, если я хочу сделать что-то плохое, зачем мне спрашивать разрешение на это? Разве это не шутка?ИЛИ Я правильно понял?

Ответы [ 3 ]

7 голосов
/ 18 октября 2010

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

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

4 голосов
/ 18 октября 2010

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

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

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

3 голосов
/ 18 октября 2010

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

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

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

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

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

...