Что мешает Microsoft встроить в API ограничения, например — любое приложение по умолчанию имеет право писать на диск только в свой профиль в My Documents, или только в файлы с заданным расширением? Если приложение запущено не из Program Files — то прав на запись на диск нет вообще? Право ставить хуки, слать оконные сообщения в чужой процесс, использовать отладочное API — только по специальному разрешению?
Для файлов *.scr — вообще никаких прав, кроме вывода на экран?
Почему они этого не сделали?

Andrei F. wrote:

> Что мешает Microsoft встроить в API ограничения, например — любое приложение по умолчанию имеет
> право писать на диск только в свой профиль в My Documents, или только в файлы с заданным
> расширением? Если приложение запущено не из Program Files — то прав на запись на диск нет вообще?
> Право ставить хуки, слать оконные сообщения в чужой процесс, использовать отладочное API — только
> по специальному разрешению? Для файлов *.scr — вообще никаких прав, кроме вывода на экран? Почему
> они этого не сделали?

Гм, и как только линух выживает...

Здравствуйте, Sheridan, Вы писали:

гусары, молчать!

Здравствуйте, Andrei F., Вы писали:

AF>Почему они этого не сделали?

Потому что это дополнительные материальные затраты, не несущие дополнительной прибыли.

Здравствуйте, ДимДимыч, Вы писали:

ДД>Потому что это дополнительные материальные затраты, не несущие дополнительной прибыли.

Как это не несущие? Надежная защита от троянцев и малвари стоит того, чтобы немного пошевелиться.
Да и затраты невелики.

Здравствуйте, Andrei F., Вы писали:

AF>Что мешает Microsoft встроить в API ограничения, например — любое приложение по умолчанию имеет право писать на диск только в свой профиль в My Documents, или только в файлы с заданным расширением? Если приложение запущено не из Program Files — то прав на запись на диск нет вообще? Право ставить хуки, слать оконные сообщения в чужой процесс, использовать отладочное API — только по специальному разрешению?
AF>Для файлов *.scr — вообще никаких прав, кроме вывода на экран?
AF>Почему они этого не сделали?

Да сделали, еще начиная с XP. Завывается ACL и priveleges. Вот только под учеткой с какими правами большинство пользователей работает?
В .NET еще дополнили CAS, но сильно помоголо, на .NET как не писали троянцев, так и не будут.

И вот в висте чтобы победить проблему сделали UAC, который права админа искуственно понижает, далеко не всем понравилась эта идея.

Здравствуйте, Andrei F., Вы писали:

AF>Что мешает Microsoft встроить в API ограничения, например — любое приложение по умолчанию имеет право писать на диск только в свой профиль в My Documents, или только в файлы с заданным расширением? Если приложение запущено не из Program Files — то прав на запись на диск нет вообще? Право ставить хуки, слать оконные сообщения в чужой процесс, использовать отладочное API — только по специальному разрешению?
AF>Для файлов *.scr — вообще никаких прав, кроме вывода на экран?
AF>Почему они этого не сделали?

Вы Windows 7 видели?

Здравствуйте, gandjustas, Вы писали:

G>Да сделали, еще начиная с XP. Завывается ACL и priveleges. Вот только под учеткой с какими правами большинство пользователей работает?

Это должно зависеть не от учетки, а от приложения. Например, приложение, которое запускается не из под Program Files — должно иметь пониженный набор привилегий.

Здравствуйте, criosray, Вы писали:

C>Вы Windows 7 видели?

Видел. Ничего интересного не нашел. Только UAC сделали немного более терпимым, хотя почти таким же бесполезным.

Здравствуйте, Andrei F., Вы писали:

AF>Здравствуйте, ДимДимыч, Вы писали:

ДД>>Потому что это дополнительные материальные затраты, не несущие дополнительной прибыли.

AF>Как это не несущие? Надежная защита от троянцев и малвари стоит того, чтобы немного пошевелиться.
AF>Да и затраты невелики.
затраты — производителю ОСи.
а трояны, малварь и прочее — зарплата производителям антивирей
чуствуешь разницу?

AF> G>Да сделали, еще начиная с XP. Завывается ACL и priveleges. Вот только под учеткой с какими правами большинство пользователей работает?

AF> Это должно зависеть не от учетки, а от приложения. Например, приложение, которое запускается не из под Program Files — должно иметь пониженный набор привилегий.

Хм. А что, в линуксе такое есть? Что-то не заметил.

Здравствуйте, Andrei F., Вы писали:

C>>Вы Windows 7 видели?

AF>Видел. Ничего интересного не нашел. Только UAC сделали немного более терпимым, хотя почти таким же бесполезным.

Плохо видели потому, что там реализована добрая половина из того, о чем Вы пишете в первом посте.

В частности, обычному пользователю запрещено писать или изменять что-то в Program Files.

Здравствуйте, criosray, Вы писали:

C>В частности, обычному пользователю запрещено писать или изменять что-то в Program Files.

Я говорил не про пользователя, а конкретную программу. Чувствуете разницу?

Здравствуйте, Andrei F., Вы писали:


C>>В частности, обычному пользователю запрещено писать или изменять что-то в Program Files.

AF>Я говорил не про пользователя, а конкретную программу. Чувствуете разницу?

Нет, не чувствую. Программы выполняются под пользователем. Не знали об этом?

Здравствуйте, criosray, Вы писали:

C>Нет, не чувствую. Программы выполняются под пользователем. Не знали об этом?

Клиент-ICQ не должен иметь никаких дисковых прав, кроме права писать в свою подпапку в Documents. И даже если его вдруг запустили под админским аккаунтом — он и у админа остается тем же клиентом-ICQ, выполняет те же функции и никаких дополнительных прав иметь не должен. Доступно?

Здравствуйте, Andrei F., Вы писали:

C>>Нет, не чувствую. Программы выполняются под пользователем. Не знали об этом?

AF>Клиент-ICQ не должен иметь никаких дисковых прав, кроме права писать в свою подпапку в Documents. И даже если его вдруг запустили под админским аккаунтом — он и у админа остается тем же клиентом-ICQ, выполняет те же функции и никаких дополнительных прав иметь не должен. Доступно?

Замечательно. А теперь расскажите пожалуйста каким образом ОС узнает о том какой программе надо разрешать писать на диск, а какой — запрещать. Внимательно слушаю.

Здравствуйте, Andrei F., Вы писали:

AF>Здравствуйте, gandjustas, Вы писали:

G>>Да сделали, еще начиная с XP. Завывается ACL и priveleges. Вот только под учеткой с какими правами большинство пользователей работает?

AF>Это должно зависеть не от учетки, а от приложения. Например, приложение, которое запускается не из под Program Files — должно иметь пониженный набор привилегий.

Угу. А теперь придумай способ гарантированного определения программы.
Особенно из глубин kernel32.dll.

Здравствуйте, criosray, Вы писали:

C>Замечательно. А теперь расскажите пожалуйста каким образом ОС узнает о том какой программе надо разрешать писать на диск, а какой — запрещать. Внимательно слушаю.

Не просто на диск, а в какие места диска. Например, запись в системные папки — по умолчанию перекрыть для всех non-system приложений.
На основании таких признаков, как
1. Установлено ли приложение в систему по всем правилам, или это, к примеру, скачанный из инета файл
2. Правила, заданные пользователем

По сути — это то же самое что фаервол, только ограничивает доступ не к удаленным, а к локальным ресурсам.

Еще вопросы?

Здравствуйте, criosray, Вы писали:

c> C>>Нет, не чувствую. Программы выполняются под пользователем. Не знали об этом?

c> AF>Клиент-ICQ не должен иметь никаких дисковых прав, кроме права писать в свою подпапку в Documents. И даже если его вдруг запустили под админским аккаунтом — он и у админа остается тем же клиентом-ICQ, выполняет те же функции и никаких дополнительных прав иметь не должен. Доступно?

c> Замечательно. А теперь расскажите пожалуйста каким образом ОС узнает о том какой программе надо разрешать писать на диск, а какой — запрещать. Внимательно слушаю.

Один из вариантов — это жесткий sandboxing, как это сделано в айфоне.

Грубо говоря:

Стандартный МакОС             iPhone

/Users                        /App1
   /Documents                     /Users
   /Desktop                       /Library
   /Applications                  /System
   /Library                   /App2
/Applications                     /Users
/Library                          /Library
/System                           /System

То есть каждое приложение имеет свою «клетку», которая выглядит, как полноценная ОСь, и за пределы этой клетки выйти не может.

Правда, такой sandboxing порождает кучу других проблем. Например — законный доступ к данным другого приложения, например.

Andrei F., правда, так и не раскрыл, в какой ОС он видел реализацию того, что он требует

Здравствуйте, gandjustas, Вы писали:

G>Угу. А теперь придумай способ гарантированного определения программы.
G>Особенно из глубин kernel32.dll.

Есть какие-то проблемы определить — из какого файла запущен процесс?