[Решено] Правильный подход к запуску графических приложений с вводом пароля

nafanja
можно было бы сделать и по другому в общем случае…
Если имеешь ввиду права доступа, то выше объяснил, что они могут изменить пароль root (даже не зная этот пароль), а потом вернуть старый пароль на место.
Не нашел ничего лучшего, как или изменить несколько байт в бинарнике или зашифровать файл. Другое на ум не приходит.
Ошибки не исчезают с опытом - они просто умнеют
vasek
если пользователь имеет физический доступ к ноуту, то он может обойти любой запрет, есть только один нюанс "вежливости"
а если, зашифровать отдельную папку, с помощью того же encfs, с нужными исполняемыми файлами, а путь к этой папке добавить в $PATH, будет лучшим вариантом чем шифровать каждый исполняемый файл... допустим шифровать /usr/local/bin/enc/
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
в этом случае можно в /usr/local/bin/enc. добавить/переместить все что нужно ограничить от исполнения другими пользователями не имеющими пароля для дешифрования.
выгода: можно вводить пароль только 1 раз, на сессию админа, а шифровать можно много исполняемых файлов и даже библиотек, если их тоже прописать правильно.
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
При такой квалификации внуков мне трудно представить прогу, которую они не смогли бы найти в инете :)
anode
При такой квалификации внуков мне трудно представить прогу, которую они не смогли бы найти в инете :)
при использовании encfs они должны будут точно знать что искать, так как имена файлов тоже шифруются...
а если они уж знают что нужно, то и защита которую предложил vasek не поможет....
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
а вообще, encfs оставляет намек на шифрование только не читаемыми именами файлов, и ключ encfs6.xml, но не читаемые имена файлов может оставить кто угодно, а encfs6.xml можно хранить в недоступном месте. двойная защита, ключом и паролем от ключа.
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
да из истории команд (которые сохраняют командные интерпретаторы) тоже можно избавится выборочно по маске пути исполнения...
ну будут знать что что-то из зашифрованной папки исполнялось, а что именно не будут знать.
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
vasek, твой промах, главное что бы внучки не читали этот форум... )))
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
anode
При такой квалификации внуков мне трудно представить прогу, которую они не смогли бы найти в инете :)
Это самописные проги, которых не найдешь в интернете. Держу, жалко выкидывать, а сам уже их и не использую.
В школе наступили каникулы, делать нечего ... и заметил, что увеличилось количество включений ноута и стал проявляться большой интерес к этим прогам.
Вообщем после разговора с родителями этих внуков пришлось вчера удалить две проги. Поматерилися, но сдался. Всем спокойнее.

nafanja
твой промах, главное что бы внучки не читали этот форум… )))
Читают ... и были даже случаи (раньше), что заходили подо мной и писали (все простые пароли мои им известны). Пришлось строго поговорить.
Ошибки не исчезают с опытом - они просто умнеют
Раз уж топик о разграничении прав, опишу один чисто теоретический нюанс подмены пароля root. С практической точки зрения интереса особо не представляет, но дает представление о том, что давать sudo не так и безопасно.
Известно, что сами пароли не хранятся, а хранятся их хэши, причем соленые. В arche используется sha512.
Всем известно, что зная хэш узнать чистый пароль не возможно - операция хэширования не обратима и все спокойны. Но есть один нюанс, как уже отметил, чисто теоретический. Зная хэш root (прописан в файле /etc/shadow), а точнее даже не хэш, а саму соль, можно сгенерить другой хэш (с нужным/известным паролем) и прописать его в shadow - получили права root не выходя из сессии, поработали и вернули старый пароль на место.
Так практически, конечно, не делается, слишком сложно, но возможность такая имеется.
Кто не верит, может проверить сам. Так что давая права sudo лишний раз подумайте. Хотя если имеется физический доступ к компу, то не нужен ни sudo ни root.
Ошибки не исчезают с опытом - они просто умнеют
 
Зарегистрироваться или войдите чтобы оставить сообщение.