[C] Безопасность библиотечных функций

При чём тут замена функций? Написано же:

Установите верно права доступа для текущего процесса

Вполне здравая мысль.

Можно поподробнее? Ато я никак не пойму как это сделать.

Кстати, очень интересно, что значит: верные права доступа процесса?

минимальные права, необходимые для работы?

Что касается access, то может лучше сразу делать с файлом open (или что там ещё), не проверяя перед этим права доступа, и проверять потом errno?

Ну хорошо. Допустим. Как мне понизить себе права, не зная ни одного непривилегированного пользователя в системе?

Я тоже об этом подумал и где можно так сделать уже сделал.

А в чём проблема с mkdir?

Узнайте про него. Из конфига, например.

Требовать для работы программы наличие в системе непривелигированного пользователя X.

у меня obsd головного мозга, т.ч. тебе может и не подойти. ;) обычно я завожу отдельного юзверя под конкретную задачу с набором груп и правами как надо, а далее

int
drop_priv(char *user)
{
        struct  passwd *pw;
        int     size = 10;
        gid_t   groups[size];

        if (!user)
                user = defuser;

        pw = getpwnam(user);

        if (!pw) {
                syslog(LOG_ERR, "no such user %s", user);
                return -1;
        }

        getgrouplist(user, pw->pw_gid, groups, &size);

        if (setgroups(size, groups) ||
            setresgid(pw->pw_gid, pw->pw_gid, pw->pw_gid) ||
            setresuid(pw->pw_uid, pw->pw_uid, pw->pw_uid)) {
                syslog(LOG_ERR, "failed to drop privs");
                return -1;
        }

        return 0;
}

        if (!user) 
                user = defuser; 

лишнее — это у меня fallback в одном поекте был

А в чём проблема с mkdir?

Функция: mkdir
Уязвимость функции:
Если атакующий сможет воспользоваться одним и тем же ресурсом в промежуток времени между вызовом mkdir() и фактическим использованием файла то он сможет воспользоваться условиями перехвата (race condition). Возникает блокировка обоих процессов или происходит сбой в программе или с возможностью получения атакующим прав суперпользователя.
Рекомендации по устранению:
Установите верно права доступа для текущего процесса (например используя setuid()) или откажитесь от использования mkdir()

Про привелегии (и не только) хорошо расписано вот в этой книге: http://oreilly.com/catalog/9780596003944

Там же на странице слева есть ссылка на исходники из книги.

Ничего не понял :). Есть более подробное/доступное описание этой проблемы с mkdir? Если есть, дайте сслыку.

>Ничего не понял :). Есть более подробное/доступное описание этой проблемы с mkdir? Если есть, дайте сслыку.

Видимо это:

http://seclab.cs.ucdavis.edu/projects/vulnerabilities/doves/2.html

Вообще мутная штука, так как mknod вроде как принимает ID пользователя при создании, а значит откуда директория, созданная с рутовскими правами. Да и вышеуказанной ссылке много лет.

Хотя если программа топикстартера работает под рутом, то может и сработает такая уязвимость.

> Функция: mkdir

Уязвимость функции:

Чувак тебе дело толкует - уязвимость на файловых операциях была довольно популярной атакой на локалхосте. В идеале, весь код, требующий рута, надо свести к минимуму, всё остальное делать от дяди васи и избегать (даже от дяди васи) неатомарных операций с ФС.

> Требовать для работы программы наличие в системе непривелигированного пользователя X.

Можно эту идею развить и требовать для работы вообще всё необходимое окружение (файлы, директории). А окружение это создавать исключительно в однопользовательском режиме, для пущей безопасности.

http://seclab.cs.ucdavis.edu/projects/vulnerabilities/doves/2.html

Это не то, не актуально для Linux, mkdir уходит прямо в ядро и сразу создается каталог с заданными правами. Последовательного вызова mknod и chown нет.

В общем, ИМХО, название топика некорректно. Дело не в уязвимости библиотечных функций, а в их некорректном использовании. Хотя не факт, что первичная проверка был корректна, может просто заметели использование access() и выдали готовый шаблон.

может просто заметели использование access() и выдали готовый шаблон.

Меня тоже посещала такая мысль, ибо упоминалось еще много подобных уязвимостей, не имеющих никакого отношения к моему проекту.

> еще много подобных уязвимостей, не имеющих никакого отношения к моему проекту.

Авторы тех проектов, в отношении которых эти уязвимости были использованы, тоже думали, что к _их_ проектам эти уязвимости никакого отношения не имеют... )))

т.е. ты предлагаешь совсем не использовать mkdir?

http://www.linux.org.ru/jump-message.jsp?msgid=4951558&cid=4953801