Все варианты не предусмотришь. Что ему мешает запустить клиент-серверное приложение, которое передает файлы? Еще как вариант, он может собрать любую утилиту из исходников или просто скопировать/скачать бинари.

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

Google is your friend!

http://serverfault.com/questions/290843/how-to-disable-sftp-for-some-users-bu...

смотри так же главу AUTHORIZED_KEYS FILE FORMAT в man sshd

Нет. Оболочка же специальная. Принимает только несколько команд. Запуск произвольного бинаря и скрипта поэтому исключён. Но надо сделать так что бы его нельзя было залить через scp. Или скажем при помощи scp подменить файл настроек.

man sshd_config

Match User youruser
ForceCommand /usr/local/bin/special.shell

scp обломится

FTP, и не парь себе мозг.

Апофеоз тупизны.

rm /usr/bin/scp? Или на этой машине он таки кому-то другому нужен?

FTP, и не парь себе мозг.

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

Нужен.

Нет. Оболочка же специальная. Принимает только несколько команд. Запуск произвольного бинаря и скрипта поэтому исключён. Но надо сделать так что бы его нельзя было залить через scp. Или скажем при помощи scp подменить файл настроек.

Там SeLinux что ли? Иначе всегда есть возможность обойти.

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

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

Запуск произвольного бинаря и скрипта поэтому исключён. Но надо сделать так что бы его нельзя было залить через scp.

монтировать раздел с noexec нэ?

как ты обойдешь, если в passwd указан какой-нибудь /usr/bin/myshell?

Или скажем при помощи scp подменить файл настроек

ro доступ к файлу настроек

монтировать раздел с noexec нэ?

Нет, совсем не то.

Читаем примерно отсюда и далее:

создание модели безопасности на основе путей, а не модификации файловой системы и введения доменов безопасности — неполноценно

как ты обойдешь, если в passwd указан какой-нибудь /usr/bin/myshell?

Читаем по ссылке:
https://en.wikipedia.org/wiki/Restricted_shell

The restricted shell is not completely secure. A user can break out of the restricted environment by running a program that features a shell function. The following is an example of the shell function in vi being used to escape from the restricted shell

А если серьёзно, то тысячи методов обхода есть, и ещё тысячи будут найдены. Потому умные дядьки и собирают системы мандатного контроля доступа — было бы всё так просто, никто б ими не занимался. Noexec, nosuid, restricted shell и пр. «олдскульные» методы обезопасивания системы — защита от дурака/скрипткидди, не более того. А лор попсеет, дуреет, потому в ветке security уже несколько лет нет никого из тех, кто хоть что-то знал про ИБ. Читайте профильные сайты по теме, pgpru тот же. Лор — место, где спецов уже нет ни по одному вопросу (когда-то были).

Нет. Оболочка самописная на три команды.

Проблема в том, что selinux излишне сложен, smack - излишне прост, а больше ничего и нет.

Ясно.. тогда придётся написать классическое клиент-серверное приложение.

Всем спасибо.

Тред не читал

Tomoyo не подойдет?

Не. Всё таки и на долгосрочную перспективу лучше сделать отдельное приложение.

классическое клиент-серверное приложение.

На мой взгляд это намного безопасней (если будет правильно реализовано), чем всякие restricted shell'ы и оболочки.