Что использовать для укрепления поля Linux? Apparmor, SELinux, grsecurity, ВКУС, chroot?
Вот другой способ сделать привязывающийся сценарий оболочки, который может предотвратить состояние состязания, которое Вы описываете выше, куда два задания могут оба передать строку 3. noclobber опция будет работать в ksh и ударе. Не использовать set noclobber потому что Вы не должны писать сценарий в csh/tcsh.;)
lockfile=/var/tmp/mylock
if ( set -o noclobber; echo "$$" > "$lockfile") 2> /dev/null; then
trap 'rm -f "$lockfile"; exit $?' INT TERM EXIT
# do stuff here
# clean up after yourself, and release your trap
rm -f "$lockfile"
trap - INT TERM EXIT
else
echo "Lock Exists: $lockfile owned by $(cat $lockfile)"
fi
YMMV с соединением NFS (Вы знаете, когда серверы NFS не достижимы), но в целом это намного более устойчиво, чем это раньше было. (10 лет назад)
Если у Вас есть задания крона, которые делают то же самое одновременно с нескольких серверов, но Вам только нужен 1 экземпляр для фактического выполнения, что-то вроде этого могло бы работать на Вас.
У меня нет опыта с lockrun, но наличие предварительно установленной среды блокировки до сценария, на самом деле работающего, могло бы помочь. Или это не могло бы. Вы просто устанавливаете тест для lockfile вне Вашего сценария в обертке, и теоретически, Вы не могли только поразить то же состояние состязания, если бы два задания назвал lockrun в точно то же время, так же, как с решением 'внутреннего сценария'?
Захват файла является в значительной степени поведением системы чести так или иначе, и любые сценарии, которые не проверяют на существование lockfile до выполнения, сделают то, что они собираются сделать. Только путем включения теста lockfile и правильного поведения, Вы будете решать 99% потенциальных проблем, если не 100%.
При столкновении с lockfile условиями состязания много это может быть индикатор большей проблемы, как не синхронизация заданий право, или возможно если интервал не так важен как завершение задания, возможно, задание лучше подходит быть daemonized.
РЕДАКТИРОВАНИЕ НИЖЕ - 06.05.2016 (если Вы используете KSH88),
Основа на комментарии @Clint Pachl ниже при использовании ksh88 использует mkdir вместо noclobber. Это главным образом смягчает потенциальное состояние состязания, но не полностью ограничивает его (хотя риск миниатюрен). Для получения дополнительной информации читайте ссылку, которую Clint отправил ниже.
lockdir=/var/tmp/mylock
pidfile=/var/tmp/mylock/pid
if ( mkdir ${lockdir} ) 2> /dev/null; then
echo $$ > $pidfile
trap 'rm -rf "$lockdir"; exit $?' INT TERM EXIT
# do stuff here
# clean up after yourself, and release your trap
rm -rf "$lockdir"
trap - INT TERM EXIT
else
echo "Lock Exists: $lockdir owned by $(cat $pidfile)"
fi
И, как добавленное преимущество, если необходимо создать tmpfiles в сценарии, можно использовать lockdir каталог для них, зная они будут очищены, когда сценарий выйдет.
Для более современного удара noclobber метод наверху должен подойти.
AppArmour, как обычно думают, более прост, чем SELinux. SELinux довольно сложен и может использоваться даже в военных применениях, в то время как AppArmour склонен быть более простым. SELinux работает на уровне i-узла (т.е. ограничения вводятся таким же образом как ACL или полномочия UNIX - с другой стороны), в то время как AppArmour применяются на уровне тракта (т.е. Вы указываете доступ на основе пути поэтому, когда изменения пути он не может применяться). AppArmour может также защитить subproccesses (только как mod_php), но я так или иначе скептически отношусь к реальному использованию его. AppArmour, кажется, находит свой путь в ядро магистрали (это находится в - мм IIRC).
Я не знаю много о ВКУСЕ, но он похож на упрощенный SELinux из описания. Существует также RSBAC, если требуется посмотреть на него.
chroot имеет ограниченный объем использования, и я не думаю, что это была бы большая часть использования в настольной среде (это может использоваться для разделения демонов от доступа целой системы - как демон DNS).
Наверняка, стоит для применения 'универсального' укрепления, такого как PaX, - fstack-средство-защиты и т.д. Chroot, который можно использовать, когда поддержки дистрибутива так делает AppArmour/SELinux. Я предполагаю, что SELinux лучше подходит для областей высокой безопасности (он имеет намного лучший контроль над системой), и AppArmour лучше для простого укрепления.
В целом я не потрудился бы укреплять универсальный рабочий стол очень, кроме выключения неиспользованных услуг, обновления регулярно, и т.д. если Вы не работаете в высоко защищенной области. Если бы Вы хотите защитить так или иначе, я использовал бы то, что поддерживает Ваш дистрибутив. Многие из них, чтобы быть эффективными потребностями поддержка приложений (для e.x. компиляция инструментов для поддержки атрибутов, записанных правил), таким образом, я советовал бы для использования то, что поддерживает дистрибутив.
Используйте GRSecurity + МИР. Все остальное просто продает bullsh*t и/или главным образом на основе работы Команды МИРА. Основной шеф разработчика МИРА, pipacs просто выиграл награду за выслугу в Black Hat 2011/PWNIE:
Его техническая работа оказала возросшее влияние на безопасность: Его идеи фундаментальны для усовершенствований в защите во всех главных операционных системах в последние годы, и его идеи имеют самые современные методы нападения повреждения памяти косвенной формы. Ни к какому взломщику нельзя отнестись серьезно в наше время, который не имеет дело с защитными изобретениями, введенными впервые нашим победителем.
Поэтому получите grsecurity+pax, если Вы действительно хотите безопасное поле. GRsec дает Вам контроль RBAC Вашей машиной, большим количеством файловой системы (chroot) базирующиеся меры защиты, PaX закрывает большую часть возможного использования хакеров векторов атаки. Можно также протестировать поле с paxtest, для наблюдения, какие меры защиты и уязвимости поле имеет.
Могло быть влияние производительности. Считайте справку :).