Hello gluck,

Wednesday, October 22, 2003, 10:57:03 PM, you wrote:

gsr> Это возможно, только если bios умеет грузится с usb. А этого не
gsr> наблюдается.
Как раз напротив - биос отлично грузится с флешек. Уже года 3 точно
умеет это делать. Проблема, в том, чтобы корректно перенести загрузочную
запись с компакт диска в згрузочный сектор флешеки, это по-моему
мнению. Как такое провернуть - не знаю (стандартный виндовый дебаггер
отказывается читать загрузочную запись компакта даже под чистым ДОС -
не знаком я с дебаггерами в Linux).

Best regards,
MapaT mailto:nemar***@y*****.ru
#178612303

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

Здравствуйте, Alexander.

Вы писали 23 Октябрь 2003 г., 0:45:54:
ASY> Думаю такая тема будет точнее отражать суть (теперь уже).
Не возвражаю. Хотя можно было оставить и file attributes

ASY> On Wed, 22 Oct 2003, Max Vasin wrote:
>> Вы правы. Разделение прав между ОС и программами и защита ОС делается и
>> сейчас режимами процессора. Насколько я понял Vasile он говорил об
>> ограничении
>> прав пользователей (от имени которых и выполняются процессы), и
>> соответсвенно
>> ограничении прав программ. Все программы кроме ядра работают на x86
>> процессорах
>> в кольце 3 - т.е. с наименьшими привилегиями, даже запускаемые root'ом.
>> В кольцо 0
>> (режим ядра) код можно запихнуть только если root загрузит
To: Max Vasin
да, я с Вами полностью согласен.

ASY> Если аппаратно поддержана защита (режим ядра/пользователя)
ASY> то все замечательно. Если нет - то система в принципе не может быть
ASY> защищена но может работать. Пока не поломают :-)
Защита несколько сложнее и включает себя использование MMU. В случае
его отсутсвия возникают проблемы реализации Linux (ядра). Однако часть
таких ограниченных архитектур всё-же обзаводится MMU (Etrax100 ->
Etrax100LX), а с другой стороны подержка остальных MMU-less систем
добавляется в uLinux и Linux 2.6.

ASY> И еще один вопрос. Наверное должен быть какой-то простой и общий алгоритм,
ASY> по которому по Effective/Real [U/G]ID вызывающего процесса и [U/G]ID
ASY> требуемого ресурса определяется нарушены ли права. Естественно считать,
ASY> что нарушение прав если (EUID<UID) OR (EGID<GID). Но по примеру,
ASY> приведенному Vasile, это не так. А как???
отношения больше/меньше здесь не верны (используются знаки равно/не равно).
Для опреедленя прав проверяются права слева на право (то есть User,
потом Group, и наконец Others); для сверки используется Efective
{U,G}ID и {U,G}ID файла (а в общем случае (semaphores, message queue,
shared memory) - ресурса).

Здравствуйте, Alexander.

Вы писали 22 Октябрь 2003 г., 23:14:13:

ASY> Почему же тогда возникают права на доступ к устройству?
ASY> Собственно тут надо понять как из [U/G]ID файла и пользователя,
ASY> запустившего файл, получаются [Real/Effective] [U/G]ID (это вроде понятно:
ASY> Real [U/G]ID := [U/G]ID пользователя, Effective ... := ... файла если
ASY> установлен соотв. бит S[U/G]ID иначе ... пользователя, так?)
Да
ASY> и как и
ASY> где ...ID процесса дальше использются (это уже непонятно). По сути надо
ASY> понять как реализуются "права в рамках ОС".
Быстрый ответ: как правило используются Efective {U,G}ID
(привык к макрорасширениям bash :)
ASY> в ман это где-нибудь есть? Почитать бы...
Отлично (и правильно - зачем в рассылке просто цитировать
документацию). Наш метод.
Теперь о документации:
Я бы посоветовал интересную книжку:
Unix. Gestionarea proceselor. Iosif Ignat, Adrian Kacso.
Cluj-Napoca 1999
но боюсь не все знакомы с румынским языком.

Книжка попроще и поновее (только по Linux'у)
Advanced Linux Programming. Mark Mitchel, Jeffrey Oldham, Alex Samuel.(2001)
Посмотрел на свою подборку электроной документации и нашёл несколько интересных
книг:
"The design of the Unix Operating System" by Maurice J. Bach (1986)
"Ядро ОС Linux. Руководство системного програмиста"
Я уверен подобной литературы достаточно, вопрос разве что в языковой
доступности.

Здравствуйте, Alexander.

Вы писали 23 Октябрь 2003 г., 0:57:27:
ASY> On Wed, 22 Oct 2003, Alexander S. Yurkov wrote:
>> Но возникает следующий вопрос. Откуда знает обработчик системного вызова
>> какой процесс его вызвал. Если передавать ему адрес заголовка процесса
>> из вызывающего процесса, то это "дыра" через которую защиту можно сломать.
>> Можно, конечно, достать со стека адрес возврата а потом найти какому
>> процессу соответствует этот адрес, но это так долго!
ASY> Впрочем, можно передать адрес заголовка a обработчик системного вызова это
ASY> проверит по адресу возврата, вытащенного из стека. Но как конкретно
ASY> реализовано в Linux?

Зачем всё усложнять: первое преимущество Unix'a - его простота (второе
- файловая система).
На самом деле вспомним что кроме режимов привилегий процессоров
(кстати верно подметили: из 4-х уровней для i386+ в Linux используются
всего лишь 2 крайних), для эфективного управления многозадачностью
используется также MMU (memory management unit)
(немного некоректно сформулировал идею, так как управление
уровнями привелегий является частью функций MMU). Я не очень хорошо
знаком с разными архитектурами систем (в частности более близкое
знакомство имел с i80x86 и Etrax100LX). Для i386 существуют понятия
GDT (Global Descriptor Table) и LDT (соотвественно Local). Они
обозначают таблицы с данными для управления областями памяти.
Существует одна GDT на всю систему, и по одной LDT для каждого
процесса. Процесс работает с виртуальными адресами (не имея понятия о
физическом распределении памяти), для правильного их отображения в
физическое адресное пространство используется LDT.
Так вот, вернёмся к Unix. Для каждого процесса выделяется зона памяти
(U-zone) содержащая набор информации о процессе. В частности там
находится время исполнения программы, приоритет, значение nice,
список открытых файлов, корень, рабочий каталог, значение umask и все
ID (uid, gid, euid, egid), ...
При системном вызове начинает исполнятся код ядра, но при этом он
выполняется в адресном пространстве пользовательского процесса (!).
Он сразу обращается к U-zone, берёт оттуда pid (process id) и если
нужная информация не находится в U-zone (например адрес буфера
открытого файла), он её ищет в соотвествующей глобальной области
данных используя идентификатор процесса (pid)
Замечание: сам процесс не имеет непосредственного доступа к
вышеописаной информации и должен использовать функции
ядра.

On Срд, 2003-10-22 at 18:45, MapaT wrote:
> Интересно было бы решить следующую задачу: создание live usb, так
> сказать. А именно: каким образом при наличии live cd Damn Small Linux перенести
> его на флэшку, с возможности загрузки с флэш диска.
Это возможно, только если bios умеет грузится с usb. А этого не
наблюдается, с другой стороны можно попробовать грузится с cd/floppy
подгружать usb-storage и далле монтировать его как /

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

Хай, линуксоиды!

Юзаю сабж.
Была пара "отключений питания", но после них во время загрузки компа
reiserfsck не включается. При проверке вручную никаких ошибок не находит.
Это нормально?

Интересно было бы решить следующую задачу: создание live usb, так
сказать. А именно: каким образом при наличии live cd Damn Small Linux перенести
его на флэшку, с возможности загрузки с флэш диска.

Best regards,
MapaT mailto:nemar***@y*****.ru
#178612303

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

On Wed, 22 Oct 2003, Max Vasin wrote:
> немножко знаю :) Насколько я понимаю процессор при возникновении прерывания
> (а в Linux именно ими делаются системные вызовы, хотя можно делать
> межстраничные
> вызовы функций с переключением контекста, AFAIK) процессор

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

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

Приветствую.

On Wed, 22 Oct 2003, Max Vasin wrote:

> немножко знаю :) Насколько я понимаю процессор при возникновении прерывания
> (а в Linux именно ими делаются системные вызовы, хотя можно делать
> межстраничные
> вызовы функций с переключением контекста, AFAIK) процессор сохраняет
> текущий
> контекст в какой-то своей структуре, по которой обработчик и определяет
> информацию
> о процессе. Это в общих словах.

IMHO в данном случае, речь идет о контексте процессора. Т.е. о его
регистрах (в т.ч. PSW и регистры управления памятью) и все. Это не то же
самое, что контекст процесса. И нечего толком из такого контекста о
процессе извлечь нельзя. Кроме адреса возврата, PSW и регистров
управления памятью.

Потом UNIX на каких только машинах не реализовывалась. Не думаю чтобы эти
вопросы на разных процессорах решались так уж по разному. Начинался UNIX
на PDP-7 (или 8?) и уж во всяком случае был на PDP-11. Как работала
команда синхронного прерывания (системный вызов это она и есть) на
PDP-11 я знаю достаточно хорошо. В стеке сохранялся програмный счетчик
и PSW вот и все. Вот и весь контекст. Ну и что в регистрах общего
назначения осталось тоже передавалось, естественно.

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

On Tue, 21 Oct 2003 21:52:42 +0000 (GMT), Alexander S. Yurkov
<fit***@o*****.com> wrote:

> On Tue, 21 Oct 2003, Антон Иванов wrote:
>> chmod +s /usr/sbin/pppd
>
> А что это означает? Я никогда и ни за какие коврижки не стану исполнять
> команду под рутовым логином, если не понимаю, что она делает...:-)

$ man chmod (можно не из под рута ;))

Если влом читать: добавить suid-бит к /usr/sbin/pppd
Прогу запускает обычныю юзер но у нее права рута.

Alexander S. Yurkov пишет:

>Приветствую.
>Думаю такая тема будет точнее отражать суть (теперь уже).
>
>On Wed, 22 Oct 2003, Max Vasin wrote:
>
>
>>>процессора доступны, и доступны все области адресного пространства
>>>(в т.ч. все апаратные регистры) то можно написать програму, которая
>>>взломает любые прграмные (в рамках ОС) привелегии. Во всяком случае на
>>>ассемблере. Или я не прав?
>>>
>>>
>>Вы правы. Разделение прав между ОС и программами и защита ОС делается и
>>сейчас режимами процессора. Насколько я понял Vasile он говорил об
>>ограничении
>>прав пользователей (от имени которых и выполняются процессы), и
>>соответсвенно
>>ограничении прав программ. Все программы кроме ядра работают на x86
>>процессорах
>>в кольце 3 - т.е. с наименьшими привилегиями, даже запускаемые root'ом.
>>В кольцо 0
>>(режим ядра) код можно запихнуть только если root загрузит
>>
>>
>
>Если я правильно понимаю, это (ограничение прав процессов) можно сделать
>одним только способом. Доступ к системным ресурсам осуществляется только
>через системные вызовы (синхронные прерывания) а уже обработчику соотв.
>синхронного прерывания вменяется в обязанность проверить права вызвавшего
>процесса. Если аппаратно поддержана защита (режим ядра/пользователя)
>то все замечательно. Если нет - то система в принципе не может быть
>защищена но может работать. Пока не поломают :-)
>
>Но возникает следующий вопрос. Откуда знает обработчик системного вызова
>какой процесс его вызвал. Если передавать ему адрес заголовка процесса
>из вызывающего процесса, то это "дыра" через которую защиту можно сломать.
>Можно, конечно, достать со стека адрес возврата а потом найти какому
>процессу соответствует этот адрес, но это так долго!
>
>
Сразу замечу: я не специалиист по защищенному режиму x86 процессоров, но
немножко знаю :) Насколько я понимаю процессор при возникновении прерывания
(а в Linux именно ими делаются системные вызовы, хотя можно делать
межстраничные
вызовы функций с переключением контекста, AFAIK) процессор сохраняет
текущий
контекст в какой-то своей структуре, по которой обработчик и определяет
информацию
о процессе. Это в общих словах. Вообще надо читать Intel Architecture
Software Developer's
Manual Volume 3, там описаны особенности реализации ОС на интеловских
процессорах
(сам читал только несколько кусочков по организации и управлению
памятью). С другой
стороны читал, что системные вызов выполняется в контексте текущем
процессе, т.е.
структры, описывающие процесс, ни откуда извлекать не надо.

>И еще один вопрос. Наверное должен быть какой-то простой и общий алгоритм,
>по которому по Effective/Real [U/G]ID вызывающего процесса и [U/G]ID
>требуемого ресурса определяется нарушены ли права. Естественно считать,
>что нарушение прав если (EUID<UID) OR (EGID<GID). Но по примеру,
>приведенному Vasile, это не так. А как???
>
>
Хороший вопрос :) Т.к. часть вызовов может выполнять только root, то для
них эта
проверка, скорее всего, реализуется простым сравнением EUID == 0.
Сложнее с проверкой
прав доступа к файлам, ведь пользователь может состоять в нескольких
группах, но в этом
случае проверка выполняется только при открытии файла, поэтому можно
допустить и простую
итеративную (по группам) проверку прав.

Привет!

С целью концентрации любителей _продуктивно_ поспорить (и просто
потолковать на любимые темы) в отдельном месте, создан новый
дискуссионный лист.

"Обсуждения и споры о свободных системах и всём сопутствующем"

http://subscribe.ru/catalog/comp.soft.linux.debate

Обсуждения достоинств и недостатков ОС: Linux, *BSD и др. Компиляторов и
средств разработки: GCC, Python, Perl, Kylix, emacs, vim, kdevelop и
др. Прикладного софта. Лицензий. Свободного распространения НЕсофта
(музыки, книг...) И многое другое!

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

Запрещается: оскорблять других участников, употреблять нецензурную
брань...

А так - общение абсолютно свободное!

Подписка на:
http://subscribe.ru/catalog/comp.soft.linux.debate

Или письмами через subscribe@subscribe.ru
(Людям у которых только почта я могу прислать приглашения на подписку).

On Wed, 22 Oct 2003, Alexander S. Yurkov wrote:
> Но возникает следующий вопрос. Откуда знает обработчик системного вызова
> какой процесс его вызвал. Если передавать ему адрес заголовка процесса
> из вызывающего процесса, то это "дыра" через которую защиту можно сломать.
> Можно, конечно, достать со стека адрес возврата а потом найти какому
> процессу соответствует этот адрес, но это так долго!

Впрочем, можно передать адрес заголовка a обработчик системного вызова это
проверит по адресу возврата, вытащенного из стека. Но как конкретно
реализовано в Linux?

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

В сообщении от 21 Октябрь 2003 12:45 Руслан Исламгалиев написал:

> Скажите, а вы с ядром и модулями точно ничего не творили? Ни с того ни с
> сего unresolved symbols не появляются.
> Неужели Mandrake поставлялся с криво собранным ядром?!

Точно ничего не делал! Одна деталь, которая, возможно, могла на что-то
повлиять: во время установки mandrake звуковуха была не до конца воткнута в
слот (кривые дрова для /dev/hands :), что выяснилось впоследствии из маздая -

звук через некоторое время пропадал. Неужели из-за этого могли появиться
unresolved symbols?

> Если есть время, могу порекомендовать собрать ядро заново. Берется vanila
> kernell, alsa-drivers и прочее необходимое. Если вы еще никогда этого не
> делали и вас интересует подобный опыт, - обещаю, вы его получите по полной
> программе.

Итак, недавно я скачал новое ядро - 2.6.0-test7, вот выдался повод
испробовать. Ядро и module-init-tools скомпилировались/установились ОК. lsmod

показывает, что модуль snd-es18xx и модули, от которых он зависит
(snd-чего-то там, их довольно много) загружены. Причём грузятся без
каких-либо warnings и т.п. Я запускал из дистриба alsa скрипт snddevices -
девайсы /dev/dsp и другие создаются ОК; а скрипт utils/alsaconfig не может
найти звуковуху. Соответственно звука нет :)

Буду благодарен за любые предложения, что можно сделать.