Как получить доступ к файлу в пользовательской папке внутри рутовой в Ubuntu?

Есть shell-скрипты и конфиги к ним, которые должны исполняться по крону, но не должны быть видимыми для пользователя, от имени которого будут исполняться - по крайней мере, он не должен наткнуться на них, гуляя по файловой системе.

Это нужно для того, чтобы потенциальный злоумышленник, получив доступ к системе от имени пользователя, не смог выкрасть пароли из конфигов, которые идут к shell-скриптам.

Пусть файлы будут такими:
/root/.crons/user_folder/user_script.sh
/root/.crons/user_folder/config.sh


Пользователь пусть будет dummy.

При этом /root и /root/.crons - принадлежат root:root.
А user_folder, user_script.sh и config.sh - принадлежат пользователю/группе dummy:dummy, и для упрощения пока поставил им всем 777.

Предполагается, что крон будет исполняться рутовый, но от имени пользователя:
* * * * * dummy /root/.crons/user_folder/user_script

Прежде чем установить такой крон, пробую от имени dummy запустить скрипт - Permissions denied.
Пытаюсь просто прочесть файл при помощи cat - Permissions denied.
Пытаюсь посмотреть содержимое папки user_folder - Permissions denied.

Мне казалось, что если моя, как пользователя, папка и файлы лежат внутри чужой, то я все равно смогу иметь к ним доступ.
Возможно, это не так. Если да, то почему?

Как можно решить задачу с сокрытием моей папки внутри папки рута (или другого пользователя)?
Как можно решить задачу иначе?
  • Вопрос задан
  • 2823 просмотра
Решения вопроса 2
jcmvbkbc
@jcmvbkbc
"I'm here to consult you" © Dogbert
Мне казалось, что если моя, как пользователя, папка и файлы лежат внутри чужой, то я все равно смогу иметь к ним доступ.
Возможно, это не так. Если да, то почему?

Это не так. Для того чтобы иметь какой бы то ни было доступ к файлу нужно иметь доступ 'x' к каждому каталогу в пути до этого файла. Т.е. для доступа к файлу /root/.crons/whatever нужно иметь 'x' к /root и 'x' к /root/.crons.
Ответ написан
Комментировать
@rPman
Если вам действительно нужно запускать приложение от текущего пользователя и скрывать пароли от него, то передавайте эти пароли в ваш скрипт при запуске через /dev/stdin и самое главное, запускайте ваши скрипты из вашего контролируемого окружения, подключившись к серверу по ssh.

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

Так же можно сами скрипты не хранить на сервере, отдавая их точно так же при запуске через stdin или пайпы/ncat/.... Практически все скриптовые интерпретаторы позволяют это, например bash -s < stream

Это не 100% защита, так как все необходимое будет лежать в оперативной памяти. пока скрипт запущен, но сложность добычи этих данных взлетает в небеса.
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
CityCat4
@CityCat4 Куратор тега Информационная безопасность
//COPY01 EXEC PGM=IEBGENER
Не трожьте домашку рута!

Домашка рута должна быть с правами 0700 root:root и ни одна собака не должна в ней рыться! Равно как и пользователи (если их несколько) с обычными правами не должны заходить в домашки друг друга! Это "личная жилплощадь" каждого.

Пароли в конфигах - это очень плохо. Это допустимо только тогда, когда невозможно никак иначе, и то я в таокм случае пишу скриптец, который пароль тривиально кодирует-раскодирует. Для общего скрипта в таком случае выделяется папка например в /usr/share, где можно для блезиру сделать еще пару уровней с ничего не говорящими названиями :), а внутри нее уже делать что надо.

Чтобы открыть файл даже на чтение у пользователя должны быть права на чтение каталога всех элементов пути. То есть, если у Вас файл лежит в /usr/share/systemscripts/default/usersettings/zhopa/zhopa.txt, то на все шесть элементов пути должны быть права по чтению.

man getfacl, man setfacl
Ответ написан
@AlexanderKomarchouk
программист PHP, embedded atmega/stm32
Здравствуйте.
Вам коллеги уже сказали, что не нужно ничего такого делать, потому что нарушается безопасность. Но если очень нужно, подумав десять раз, то можно сделать то что вы хотите.

В 199затертом году тоже возникала похожая задача. Нужно было "что то" делать, но обычные пользователи не должны были знать некоторую информацию, доступную только для root.
Вы можете использовать возможности операционной системы Unix/Linux, setuid - "установка ID пользователя во время выполнения".
Создайте тестовую программу, назовем её startuid.c:
// startuid.c
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>
#include <sys/wait.h>

int main(void)
{
   pid_t child_pid;

    printf("Real UID\t= %d\n", getuid());
    printf("Effective UID\t= %d\n", geteuid());
    printf("Real GID\t= %d\n", getgid());
    printf("Effective GID\t= %d\n", getegid());
   
   if((child_pid = fork()) < 0 )
   {
      perror("fork failure");
      exit(1);
   }

   if(child_pid == 0)
   {
      execl("/bin/ls", "ls", "-l", "/root", (char*)0);
      perror("execl() failure!\n\n");
      _exit(1);
   }
    return EXIT_SUCCESS;
}

Скомпилируйте startuid.c, и скопируйте результат в домашнюю директорию обычного пользователя, например alex, который должен будет выполнить нужную вам команду с идентификатором uid=0(root).
[Unix]# ls -l
-rwxr-xr-x 1 root root 7348 Jul  2 18:19 startuid

используйте chmod для установки атрибута setuid
[Unix]# chmod u+s startuid
[Unix]# ls -l
-rwsr-xr-x 1 root root 7348 Jul  2 18:19 startuid

До установки атрибута setuid, и запуска startuid от пользователя alex, выполняющий "ls -l /root" (листинг домашнего каталога пользователя root ) выдавал ошибку "Permission denied". После установки атрибута setuid, и запуска startuid вы получали список файлов в каталоге пользователя root.
Само собой запуск "ls -l /root" это просто пример, вместо этого вы можете написать ту команду, которую вам надо выполнить обычным пользователем от рута.
Кроме того, возможно вам пригодится почитать про Sticky bit
Удачи, и будьте осторожны.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы