Сценарий может быть исполняемым файлом, но не читаемый?

Это не возможно, по крайней мере, на Linux (другие Нельды могли бы позволить его); думайте об этом, когда Вы запускаете скрипт, оболочка должна считать его для знания, что сделать.

Это возможно только для двоичных файлов.

$ chown foo:foo bar
$ chmod 701 bar

Как непривилегированный пользователь:

$ ls -lha bar
-rwx-----x 1 foo foo 7.0K 2012-03-15 03:06 bar

$ cat bar
cat: bar: Permission denied

$ ./bar
baz

Теперь, вот строка над заголовком. В то время как файл нечитабелен стандартными средствами, Вы не можете на самом деле предотвратить чтение файла. Это - на самом деле проблема на http://smashthestack.org/ (уровень 13). Существует известная названная утилита hktrace это позволяет Вам читать использование файла ptrace.

Я думаю, можно сделать это с setuid.

За исключением того, что Вы не можете, потому что большинство дистрибутивов (по-видимому), имеет setuid отключенный, потому что это - крупная дыра в системе безопасности. Это отключено на моем, таким образом, я на самом деле не знаю, что этот ответ будет работать, я отправляю его так или иначе, потому что я думаю, что это должно.

Так или иначе, если я хотел сделать то, что Вы хотели сделать - и у меня был дистрибутив с setuid включенный для сценариев - я сделал бы что-то как:

$ chmod 700 myscript
$ cat > myscript-nonroot
#!/bin/sh
bash myscript
^D
$ sudo chown root:root myscript-nonroot
$ sudo chmod 4755 myscript-nonroot # make SURE this isn't world-writable!

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

Так как myscript-некорневая функция читаема всеми, кого она может быть считана и выполнена, и к тому времени, когда Вы добираетесь два строка, где Вы на самом деле выполняете свой сценарий (bash myscript) это выполняется как корень (или кого бы ни еще Вы хотите, точный пользователь не имеет значения, пока файл обертки принадлежит тому же пользователю.)

На этой ситуации я использовал sudo с опцией NOPASSWD, таким образом, пользователи могут запустить скрипт не имея возможности для чтения его.

Существует половина истины к предыдущим операторам. Можно установить сценарий так, чтобы это не было читаемо пользователем, но все еще исполняемо. Процесс немного вытянут, но это выполнимо путем создания исключения в/etc/sudoer так, чтобы пользователь мог запустить скрипт как самостоятельно временно, не будучи предложенным пароль. Этот метод: - обходит патч setuid для других дистрибутивов. - позволяет Вам давать поднятые полномочия временно для определенного сценария, не давая пользователю sudo права на все.

Следуйте инструкциям на этом сообщении: разрешение Файла выполняется только

Чтобы сделать ваши скрипты нечитаемыми, но исполняемыми, у вас есть 3 основных варианта:

Первый вариант

Используйте команду openssl, чтобы вручную зашифровать его. А в будущем, когда вы захотите запустить сценарий, вам придется снова запускать openssl вручную и указывать пароль для расшифровки.

Шифрование с помощью openssl:

cat yourscript.sh | openssl aes-128-cbc -a -salt -k yourpassword> yourscript.enc

Расшифровка с помощью openssl:

cat yourscript.enc | openssl aes-128-cbc -a -d -salt -k yourpassword> yourscript.dec

yourscript.dec будет таким же, как ваш исходный скрипт yourscript.sh

Второй вариант

Используйте сайт вроде www.Enscryption.com , чтобы автоматически зашифровать ваш сценарий и сделать зашифрованную версию исполняемого файла. Этот сайт использует возможности шифрования openssl и некоторые другие методы обфускации, чтобы злоумышленникам было довольно сложно проникнуть в ваш скрипт или раскрыть секреты, которые вы хотите скрыть. С помощью этого сайта вы можете шифровать сценарии оболочки и сценарии командной строки на perl, python, ruby. Я тоже думаю, что php.

Третий вариант

Используйте такой инструмент, как shc . Похоже, он не обновлялся с 2012 года. Но я использовал его раньше. Вы должны скомпилировать свой сценарий для каждой ОС, в которой вы хотите его использовать, если ОС отличается от той, которую вы использовали для ее компиляции.

Резюме:

Если скрытие кода имеет для вас большое значение, полагаться только на разрешения и право владения поможет вам, поскольку любой пользователь root может получить к нему доступ. Это факт.Что вы можете сделать, если действительно хотите предотвратить несанкционированный просмотр вашего кода кем-либо, - это написать сценарий вокруг команды openssl. Сделайте так, чтобы перед запуском скрипта он запрашивал пароль, а после его ввода он запускал скрипт, не записывая его во временный файл. Если это звучит слишком много, то вариантов 2 и 3 должно быть достаточно для ваших целей.

Работает на OpenBSD

Как уже упоминалось в комментарии @eradman, это возможно в OpenBSD.

Как root:

hzy# cat <<'EOT' >/tmp/foo; chmod 001 /tmp/foo
#! /bin/sh
: this is secret
echo done
EOT

Как обычный пользователь:

hzy$ cat /tmp/foo
cat: /tmp/foo: Permission denied
hzy$ /tmp/foo
done

Это работает путем передачи интерпретатору/dev/fd/3(или любого другого открытого fd для сценария ). Этот трюк не будет работать в Linux, где /dev/fd/Nне специальные символьные устройства, которые возвращают dup(2)fd при открытии, а «волшебные» символические ссылки на исходный файл/dentry,которые открывают файл с нуля [1]. Это может быть реализовано в Free/NetBSD или Solaris...

Но это не то, чем кажется

По сути, предоставление разрешенияx(на выполнение )означает также предоставление разрешенияr(на чтение )для любого файла, имеющего шебанг [2]:

hzy$ cat /tmp/foo
cat: /tmp/foo: Permission denied
hzy$ ktrace -ti /tmp/foo
done
hzy$ kdump | tail -n8
 70154 sh       GIO   fd 10 read 38 bytes
       "#! /bin/sh
        : this is secret
        echo done
       "
 70154 sh       GIO   fd 1 wrote 5 bytes
       "done

ktraceне единственный путь; если интерпретатор представляет собой динамически связанный исполняемый файл, такой как perlили python, вместо него можно использовать хак LD_PRELOAD, который переопределяет функцию read(2).

И нет, установка setuid не помешает обычному пользователю видеть его содержимое; она может просто запустить его под ptrace(2), что приведет к игнорированию битов setuid:

Как root:

hzyS# cat <<'EOT' >/tmp/bar; chmod 4001 /tmp/bar
#! /bin/sh
: this is secret
id
EOT

Как обычный пользователь:

hzyS$ ktrace -ti /tmp/bar
uid=1001(duns) euid=0(root) gid=1001(duns) groups=1001(duns)
hzyS$ kdump
   ... nothing, the kernel disabled the ktrace...
hzyS$ cc -Wall -xc - -o pt <<'EOT'
#include <unistd.h>
#include <sys/types.h>
#include <sys/ptrace.h>
#include <sys/wait.h>
#include <signal.h>

int main(int ac, char **av){
        int s; pid_t pid;
        if((pid = fork()) == 0){
                ptrace(PT_TRACE_ME, 0, 0, 0);
                execvp(av[1], av + 1);
        }
        while(wait(&s) > 0 && WIFSTOPPED(s)){
                s = WSTOPSIG(s);
                ptrace(PT_CONTINUE, pid, (caddr_t)1, s == SIGTRAP ? 0 : s);
        }
}
EOT
hzyS$./pt ktrace -ti /tmp/bar
uid=1001(duns) gid=1001(duns) groups=1001(duns)
hzyS$ kdump | tail -5
 29543 sh       GIO   fd 10 read 31 bytes
       "#! /bin/sh
        : this is secret
        id
       "

(извините, если это не самый простой способ продемонстрировать это)

[1] это можно эмулировать в Linux с помощью binfmt_misc, но потребуется изменить интерпретатор или использовать оболочку; см. последнюю часть этого ответа для примера преднамеренно сделанного смехотворно небезопасным.

[2] или вообще любой файл, который не приведет к возврату execve()ENOEXEC.