Добрый день коллегам!
Простите за тупейший вопрос. А именно - по дефолту юзер в Linux'е может создать файл с правами rw-rw-r-- (то есть не может поставить атрибут х) и это правильно. Однако столкнулся с не очень приятной вещью - беру (в сеансе юзера) флешку, подключаю её к компьютеру и вижу, что там файло с установленным битом 'х', то есть - исполняемое. А это не есть правильно. Более того, если юзер качает на флешку свое файло, то оно тоже приобретает исполняемый атрибут. После чего копируем обратно и...
Итак, вопрос - где собака зарылась? Как настроить систему (Fedora), в каком файле отметить, чтобы файлы на FAT[xx]-девайсах (флешках и прочих отчуждаемых носителях) не приобретали при монтировании этих девайсов атрибут исполняемых?
LinuxForum.Fans
Q по правам на FAT32-флешке
Автор: Cruiser78
18 сообщений
3103 просмотров
Итак, вопрос - где собака зарылась? Как настроить систему (Fedora), в каком файле отметить, чтобы файлы на FAT[xx]-девайсах (флешках и прочих отчуждаемых носителях) не приобретали при монтировании этих девайсов атрибут исполняемых?
а как вы монтируете? через что?
вот там и пропишите noexec. и fmask=333
как вы монтируете? через что?
вот там и пропишите noexec. и fmask=333
Если бы я знал, как оно по дефолту в Федоре монтируется. Сейчас кувыркаюсь с правилами udev. Не выходит каменный цветок.
А именно вот правила в udev:
text
ACTION=="add" KERNEL=="sd[c-z][0-9]" RUN+="/bin/mkdir -p /mnt/flash"
ACTION=="add" KERNEL=="sd[c-z][0-9]" RUN+="/bin/mount -o rw,flush,quiet,nodev,noauto,noexec,nosuid,noatime,dmask=000,fmask=111,iocharset=utf8 /dev/%k /mnt/flash"
ACTION=="remove" KERNEL=="sd[c-z][0-9]" RUN+="/bin/umount /dev/%k"
ACTION=="remove" KERNEL=="sd[c-z][0-9]" RUN+="/bin/rmdir /mnt/flash"
А вот вывод сислога:
text
Sep 14 11:37:34 admin-lvs kernel: usb 1-4: new high speed USB device using ehci_hcd and address 11
Sep 14 11:37:35 admin-lvs kernel: usb 1-4: New USB device found, idVendor=0bb4, idProduct=0c13
Sep 14 11:37:35 admin-lvs kernel: usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Sep 14 11:37:35 admin-lvs kernel: usb 1-4: Product: Storage
Sep 14 11:37:35 admin-lvs kernel: usb 1-4: Manufacturer: HTC
Sep 14 11:37:35 admin-lvs kernel: usb 1-4: SerialNumber: 3fbf5000-7351-0801-3553-040201152230
Sep 14 11:37:35 admin-lvs kernel: scsi12 : usb-storage 1-4:1.0
Sep 14 11:37:36 admin-lvs kernel: scsi scan: INQUIRY result too short (5), using 36
Sep 14 11:37:36 admin-lvs kernel: scsi 12:0:0:0: Direct-Access PQ: 0 ANSI: 0
Sep 14 11:37:36 admin-lvs kernel: sd 12:0:0:0: Attached scsi generic sg3 type 0
Sep 14 11:37:36 admin-lvs kernel: sd 12:0:0:0: [sdc] 7733248 512-byte logical blocks: (3.95 GB/3.68 GiB)
Sep 14 11:37:36 admin-lvs kernel: sd 12:0:0:0: [sdc] Write Protect is off
Sep 14 11:37:36 admin-lvs kernel: sd 12:0:0:0: [sdc] Assuming drive cache: write through
Sep 14 11:37:36 admin-lvs kernel: sd 12:0:0:0: [sdc] Assuming drive cache: write through
Sep 14 11:37:36 admin-lvs kernel: sdc:
Sep 14 11:37:36 admin-lvs kernel: sd 12:0:0:0: [sdc] Assuming drive cache: write through
Sep 14 11:37:36 admin-lvs kernel: sd 12:0:0:0: [sdc] Attached SCSI removable disk
В результате то, что я указываю в udev'е - накрывается медным тазом, каталог заданный (/mnt/flash) даже не создается, а флешка монтируется в /media/flash-label. И с правами на файлы - исполняемый. Да, кстати, у меня не совсем флешка, а коммуникатор HTC Diamond, но это же не имеет значения? Ведь df -h говорит на него следующее:
text
/dev/sdc 3,7G 3,2G 499M 87% /media/0800-002FНе понимаю...
=============================================
Нет, здесь, с udev, разобрался. Собака зарылась в записи sd[c-z][0-9]. А у меня создается только sdc, без номера. Вот udev и спотыкался. Убрал номер и udev флешку подхватил правильно. С атрибутами, как в опциях прописано.
Однако вопрос не закрыт - какая сволочь в Fedora-13 по дефолту монтирует абы-как флешки и как её научить делать это правильно? Настройка udev'а - это, на мой взгляд, небольшой костыль... По дефолту флешки то на рабочем столе отображаются как различные "девайсы", а с udev'ом - только тривиальный том. Причем том, который юзер не враве сам размонтировать (не настроил я это право).
Однако вопрос не закрыт - какая сволочь в Fedora-13 по дефолту монтирует абы-как флешки и как её научить делать это правильно?
без понятия. может HAL? или DeviceKit?
я сам ничего понять не могу...
без понятия. может HAL? или DeviceKit?
я сам ничего понять не могу...
Да, забыл упомянуть - может это важно - юзаю GNOME. И он по дефолту очень так услужливо монтирует ФАТ-"флешки" (иного не имею) так, что файло на них получает по дефолту атрибут х. Именно по дефолту, так как специально я такого не настраивал.
А разве фат поддерживает разрешения прав доступа на файло? oO
Да, забыл упомянуть - может это важно - юзаю GNOME. И он по дефолту очень так услужливо монтирует ФАТ-"флешки" (иного не имею) так, что файло на них получает по дефолту атрибут х. Именно по дефолту, так как специально я такого не настраивал.
я в курсе:
text
dev/hdc on /media/CD type iso9660 (ro,nosuid,nodev,uhelper=hal,uid=1000,utf8)в кедах та же беда. у меня монтируется через HAL, но как это настраивается - без понятия.
Ведь откуда-то это берётся...
народ в сети уже исходники правит (только я не понял чего): http://www.linuxquestions.org/questions/slackware-14/forcing-noexec-as-a-hal-mount-option-651422/
И решения похоже нет :(
А разве фат поддерживает разрешения прав доступа на файло?
нет конечно. вопрос о том, как это смонтировать без права на исполнение.
блин, действительно в slackware-13.0-install-d2/source/l/hal/hal-0.5.11.tar.xz есть такой файл, сейчас попробую пересобрать HAL...
блин, действительно в slackware-13.0-install-d2/source/l/hal/hal-0.5.11.tar.xz есть такой файл, сейчас попробую пересобрать HAL...
Сие подходит для "дома, для семьи". Но это же неправильно для "промышленной" эксплуатации. Пересобирать ядра на многих компьютерах. А если пойдет обновление? Все по новой? Это никуда не годится. И дыра в секурности шире маминой... Юзер с помощью флешки ставит атрибут исполняемый на собственные файлы. И куда смотрит партия и правительство?.. :-(
Сие подходит для "дома, для семьи". Но это же неправильно для "промышленной" эксплуатации. Пересобирать ядра на многих компьютерах.
зачем ядра-то? это просто костыль для автомонтирования. в промышленной эксплуатации таких костылей не нужно. Да их там и нет. Внешние носители - несекьюрно по определению, особенно когда они монтируются кем угодно, и когда угодно (для чего HAL и создан).
А если пойдет обновление? Все по новой?
не пойдёт. HAL УЖЕ устаревший. Потому грозят лишь секьюрные обновления, а это не страшно - HAL можно в случае чего просто вырубить нафиг, не велика потеря.
И дыра в секурности шире маминой... Юзер с помощью флешки ставит атрибут исполняемый на собственные файлы. И куда смотрит партия и правительство?.. :-(
ну и пусть ставит, жалко что-ли? в архивах он тоже ставится, и ничего.
Внешние носители - несекьюрно по определению, особенно когда они монтируются кем угодно, и когда угодно (для чего HAL и создан).
Здесь всё зависит от политики организации (в смысле, что контора делать допускает). И эти политики могут допускать разное. Если у нас нет больших секретов, то почему надо запрещать отчуждаемые носители? Если не боимся утечки, то монтируй их в режиме RW. Если опасаемся утечки, то следует монтировать такие носители в режиме RO. И фиг ты на него (без вмешательства рута) запишешь что.
А вот атрибут Х лучше прибить, так как его несанкционированное наличие может серьезно повлиять на работоспособность нашего комплекса.
И это должно достаточно легко правиться. Вот только где???
ну и пусть ставит, жалко что-ли? в архивах он тоже ставится, и ничего.
1. Не жалко. Пусть ставят. Но пусть не имеют возможности запускать то, что поставили. Мне потом лишний головняк не нужен - компьютеры поднимать... Компьютер на более-менее серьезной фирме должен кормится только с одной руки. Админинистраторской. Иначе проблемы у админа неизбежны.
2. Про архивы - можно чуть поподробнее?
И это должно достаточно легко правиться. Вот только где???
не должно. автоматическое монтирование предполагает незащищённость. можно не всех юзверей пихать в группу plugdev, тогда не все получат право монтирования.
1. Не жалко. Пусть ставят. Но пусть не имеют возможности запускать то, что поставили. Мне потом лишний головняк не нужен - компьютеры поднимать... Компьютер на более-менее серьезной фирме должен кормится только с одной руки. Админинистраторской. Иначе проблемы у админа неизбежны.
2. Про архивы - можно чуть поподробнее?
1) тогда монтируйте noexec ВСЕ разделы, к которым у пользователя есть право на запись. Возможность такая у вас есть.
ну пишут-же:
WARNING: PolicyKit is disabled. You need to manually edit the hal.conf
file to lock down the service. Failure to do so allows any
caller to make hald do work on their behalf which may be
a huge SECURITY HOLE. I repeat: YOU NEED TO EDIT THE FILE
hal.conf to match your distro/site to avoid NASTY SECURITY HOLES.
такие дела, Настя, и твои отвратительные дырочки ;)
(слово NASTY гуглопереводчик переводит как "Настя", чем немало доставляет :) )
2) что тут подробнее?
[console]doc@bx:~$ mkdir source/test
doc@bx:~$ cd source/test
doc@bx:~/source/test$ cat >test.c
int main()
{
return 0;
}
doc@bx:~/source/test$ gcc -o virus test.c
doc@bx:~/source/test$ ll
итого 12
-rw-r--r-- 1 doc users 26 2010-09-15 12:15 test.c
-rwxr-xr-x 1 doc users 6380 2010-09-15 12:16 virus*
doc@bx:~/source/test$ tar -cJvvf 1.txz *
-rw-r--r-- doc/users 26 2010-09-15 12:15 test.c
-rwxr-xr-x doc/users 6380 2010-09-15 12:16 virus
doc@bx:~/source/test$ rm -vf [^1]*
удален `test.c'
удален `virus'
doc@bx:~/source/test$ ll
итого 4
-rw-r--r-- 1 doc users 2440 2010-09-15 12:17 1.txz
doc@bx:~/source/test$ tar -xvvf 1.txz
-rw-r--r-- doc/users 26 2010-09-15 12:15 test.c
-rwxr-xr-x doc/users 6380 2010-09-15 12:16 virus
doc@bx:~/source/test$ ll
итого 16
-rw-r--r-- 1 doc users 2440 2010-09-15 12:17 1.txz
-rw-r--r-- 1 doc users 26 2010-09-15 12:15 test.c
-rwxr-xr-x 1 doc users 6380 2010-09-15 12:16 virus*
[/console]
видно, что юзер с лёгкостью извлёк исполняемый файл. Так чем флешка опаснее архива?
А разве фат поддерживает разрешения прав доступа на файло?
Нет, но в ФС, которые не поддерживают прав доступа как таковых, при монтировании можно задать так называемую маску, которая определяет права доступа ко всем файлам (ну или отдельно к файлам и к каталогам), ведь в POSIX-системе у каждого файла должны быть хоть какие-то права доступа. Разумеется, после монтирования менять эти права уже невозможно. Можно только перемонтировать с новой маской.
Проблема состоит в том, что по умолчанию эта маска делает все файлы исполняемыми. Меня, к примеру, это мало смущает, но...
2) что тут подробнее?
Понял. Но пример немного некорректен. Я не совсем понял вывод первого ll. Какой umask стоит у пользователя? 22? А почему не поставить 133? И отобрать umask от пользователя? Тогда:
[console]doc@bx:~/source/test$ ll
итого 12
-rw-r--r-- 1 doc users 26 2010-09-15 12:15 test.c
-rw-r--r-- 1 doc users 6380 2010-09-15 12:16 virus*
[/console]
Далее - покоцано.
Правда, (неприятное открытие) у меня chmod позволяет юзеру поставить любой атрибут на собственный файл. Надо тщательно раскурить еще и это поведение нехорошее.
Я так понимаю, что есть "нечто" в настройках юзера, что определяет его дефолтные права на файловой системе. Далее, на это "нечто" накладывается umask и несколько обрезает это нечто. Что влияет на процедуру назначения прав при создании файла. Результат обрезания этого "нечта" чуть выше - у меня virus исполняемым при umask=133 не стал. Однако chmod, а следом за ним и иные программы, на umask внимания почему-то не обращают. И спокойно ставят атрибуты не превосходящие этого "нечто". Если это нечто обрезать юзеру изначально, то юзер сможет, например, изменять стандартным образом атрибуты чтения-записи, но не сможет выставить атрибут "исполняемый".
Тогда и "исполняемый" файл в архиве при распаковке его юзером просто потеряет атрибут исполняемости. Тот же tar не сможет этот атрибут установить на распаковываемом файле.
Отсюда вопрос - что это за "нечто", как оно называется правильно и где конфигурируется?
Меня, к примеру, это мало смущает, но...
Но, вполне возможна ситуация, когда есть некие программы, которые юзеру запускать не следует. Но по каким то причинам они доступны ему на чтение. Тогда юзер просто копирут их на флешку и эти команды становятся для юзера исполняемыми...
Понял. Но пример немного некорректен. Я не совсем понял вывод первого ll. Какой umask стоит у пользователя? 22? А почему не поставить 133? И отобрать umask от пользователя? Тогда:
она и так 0133. все файлы создаются со сброшенным правом исполнения (а каталоги - наоборот).
Да, и umask у юзера отобрать невозможно - только вместе с bash'ем.
А тут случай особый - я использовал gcc, а этот компилятор сам устанавливает право исполнения на исполняемый файл, который создаёт.
Далее - покоцано.
Правда, (неприятное открытие) у меня chmod позволяет юзеру поставить любой атрибут на собственный файл. Надо тщательно раскурить еще и это поведение нехорошее.
можете не утруждаться: действительно, владелец файла вправе ставить ЛЮБЫЕ права доступа на свои файлы. И не только сам владелец, но и его программы, в т.ч. и вредоносные :(
Я так понимаю, что есть "нечто" в настройках юзера, что определяет его дефолтные права на файловой системе. Далее, на это "нечто" накладывается umask и несколько обрезает это нечто. Что влияет на процедуру назначения прав при создании файла.
всё верно.
Результат обрезания этого "нечта" чуть выше - у меня virus исполняемым при umask=133 не стал. Однако chmod, а следом за ним и иные программы, на umask внимания почему-то не обращают.
ИМХО вы тут ошибаетесь - скажите спасибо мудрым создателям gcc, что их компилятор обращает внимание на вашу umask. Хотя не обязан вообще-то.
The umask is used by open(2), mkdir(2), and other system calls that create files to modify the permis‐
sions placed on newly created files or directories. Specifically, permissions in the umask are turned
off from the mode argument to open(2) and mkdir(2).
The constants that should be used to specify mask are described under stat(2).
The typical default value for the process umask is S_IWGRP | S_IWOTH (octal 022). In the usual case
where the mode argument to open(2) is specified as:
S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH
(octal 0666) when creating a new file, the permissions on the resulting file will be:
S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH
(because 0666 & ~022 = 0644; i.e., rw-r--r--).
иными словами, маска для новых файлов равна 0666, но на неё накладывается umask, и получается 0666 & ~0022 == 0644. Тем не менее, кодер может задавать вообще ЛЮБЫЕ права для новых файлов, и они будут работать, даже если ФС не поддерживает (например можно создать файл с правом исполнения, на разделе смонтированном как -o noexec. Конечно исполнять его оттуда не получится, за то можно скопировать и выполнить).
Тогда и "исполняемый" файл в архиве при распаковке его юзером просто потеряет атрибут исполняемости. Тот же tar не сможет этот атрибут установить на распаковываемом файле.
да нет никакого "нечто". Есть просто права, и всё. tar эти права сохраняет, а потом восстанавливает (если сможет).
Отсюда вопрос - что это за "нечто", как оно называется правильно и где конфигурируется?
ответ: нет никакого "нечто". Если кодеру лениво, то компилятор за него поставит 0666, а во время исполнения это сложится с 0022, и получится 0644. Тем не менее, кодер может:
1) использовать другой шаблон, например 0777, как gcc, и с дефолтной маской это даёт 0755.
2) создать файл, а потом поменять его права. тут и umask не поможет.
3) поменять umask - в пределах своей программы.
И ничего вы тут не поделаете.
Но, вполне возможна ситуация, когда есть некие программы, которые юзеру запускать не следует. Но по каким то причинам они доступны ему на чтение. Тогда юзер просто копирут их на флешку и эти команды становятся для юзера исполняемыми...
что помешает юзверю скопировать файл, и поставить на него u+x ? Врождённая тупость? не... злоумышленник по определению в разы умнее нас...
не... злоумышленник по определению в разы умнее нас...
Безусловно умнее. Поскольку в отличие от честного админа копает одну ямку, но глубоко. А админ вынужден копать широко (в результате с глубиной проблемы).
Но только одного не пойму - почему с таким подходом юниксы еще не захлестнула волна вирусов. Как Вынь? Типовая технология та же - скачивается в бровсере интрудеский код, [вызывается chmod u+x], запускается... Только то, что бровсер юниксовый чуть-чуть ограничен чем IE?
Войдите или зарегистрируйтесь, чтобы ответить.
