>>>>Take a look at sudo.
>>>
>>>Использование sudo в CGI-скриптах - это практически добровольное выкапывание могилы для своего
>>>сервера, либо для скрипта использующего sudo нужно заводить отдельный виртуальный хост,
>>>запускать с помощью suexec под отдельным UID, настроить sudo для этого
>>>UID в максимально урезанном варианте и провести наидетальнейший аудит всего кода
>>>скрипта.
>>
>>Hi,
>>
>>Completely agree about virtual host, etc. Defered invocation proposed by you in
>>the previous message may be (see below) safer but in many
>>cases you need "immediate" system reaction.
>>
>
>это не система обслуживания в режиме реального времени, такчто некоторые задержки (если
>они, тем более, диктуются соображениями безопасности) допустимы.
>
>>I said may be because even if you write something to the
>>intermediate file you actually have to be very careful with croned
>>script too. Basically croned script will use contents of your intermediate
>>file like input parameters, this means that in both cases (CGI
>>and croned script) You basically should check input parameters and invalidate
>>everything unsafe (IFS; PATH; exec; eval etc.)
>>So this audit should be mostly the same. :)
>>
>>Thanks
>>--- Sas
>>
>>
>
>В скрипте, я анализируя входящие параметры могу давать тот доступ, точно такой,
>которуй нужно - И НЕ ВЫШЕ, а не рутовый (или другой
>привелированнй). Так что аутентификация - аутентификацией, а авторизация - авторизацией (
>не стОит путать эти две разные вещи). Hi Ls,
Sorry for english (which is not so good as I want it to be).
Let me copy original post from Борис here:
Проблема: система FreeBSD.
нужно через веб-интерфейс добавлять пользователя, менять пароли, но, насколько я понял, апач выполняет скрипты с правами nobody (как мы его и пустили).
Попробовал для этих целей использовать pw, chpass, написал сишный скриптик, в котором делал exevp(...) потом поставил chmod 5755 на этот скрипт (посоветовали). pw отрабатывает нормально даже для не рута. Но вот chpass - ни в какую - пишет Permission denied :(((
Вопросы:
1. Что можно сделать в данной проблеме?
2. Может есть другой способ?
Заранее все большой сенкс!
1. In the original post author DID not tell us about system's requirements. That is why I just pointed out that for "real time" systems you have to use other solution. BTW I'm not saying only one. It can be something else more appropriate.
2. Regarding safety I'm still not sure, that this solution is much safer because:
a) cgi is working under nobody or some other low privileged user.
b) only some operations are used to be called using sudo. BTW quote from sudo man:
"sudo allows a permitted user to execute a command as the supe?ruser or ANOTHER user"
That means you can use fine grained security model here (without "HIGH" permissions).
c) If you execute something you have to be ALWAYS very careful with input parameters. It does not matter from where you get it! For example consider case (very primitive and probably not related to change user's password problem) where I have croned script which should execute some command from intermediate file:
# ---- croned script starts ----
#!/bin/bash
for c in `cat my_intermediate_command_file`; do
# --- no checks for input parameters...
eval $c
done
# --- croned script ends ----
# --- contents of the my_intermediate_command_file starts ---
rm -Rf /
echo Thanks a lot for o simple solution
# --- conttents of the my_intermediate_command_file ends ---
This even more important, because in the proposed solution (see quote below) author suggested to use "root cron".
Ничего не меняй напрямую, лишь создавай флаговый файлик, например для изменения пароля, формата: "login passwd". Далее раз в минуту из рутового крона запускай менеджер командных файлов, которая разгребает эти файлы и реализует в зависимости от файла нужное действие.
I know, that author proposed to use login/password pair etc (which should be safe). But if passwd has some buffer overflow? In that case we can end up with the compromized system very quickly. This means that in any case the most important part is to check input parameters.
e) Regarding authentication/authorization: Where did you see me or somebody else mention this stuff in the thread? :) You have to read properly. It is completely unrelated to discussion. It should be done long before cgi script call... :)
Conclusion:
===========
Sudo can be used from cgi or (to add another level of indirection and time delay (which is necessary sometimes)) from croned script (but not root cron) and it will be good solution. Programmer/admin should work together to provide safe solution (virtual hosts; users etc.) Input parameters should be always treated with special attention.
Thanks
--- Sas
