Comment empêcher un processus d'écrire des fichiers

13

Je veux exécuter une commande sous Linux d'une manière qui ne puisse pas créer ou ouvrir de fichiers à écrire. Il devrait toujours être capable de lire des fichiers comme d'habitude (donc un chroot vide n'est pas une option), et toujours être capable d'écrire sur des fichiers déjà ouverts (en particulier stdout).

Des points bonus si l'écriture de fichiers dans certains répertoires (ie le répertoire courant) est toujours possible.

Je recherche une solution qui soit locale au processus, c'est-à-dire qui n'implique pas la configuration de choses comme AppArmor ou SELinux pour l'ensemble du système, ni les privilèges root. Cependant, cela peut impliquer l'installation de leurs modules du noyau.

Je cherchais des capacités et celles-ci auraient été agréables et faciles, s'il y avait eu une capacité de création de fichiers. ulimit est une autre approche qui serait pratique, si elle couvrait ce cas d'utilisation.

Joachim Breitner
la source
Trop de programmes supposent qu’ils sont capables d’écrire des fichiers naturellement (et échouent de façon étrange s’ils ne le peuvent pas). stracevous indique quels fichiers le programme ouvre. Pourquoi veux-tu faire cela? Est-ce un programme spécifique, ou voulez-vous le tester ou autre chose? Pouvez-vous exécuter le programme en tant qu'utilisateur / groupe qui n'a pas la permission d'écrire presque partout sauf dans le répertoire courant? Les distributions Linux modernes utilisent l'idée d'un groupe pour chaque utilisateur, donc cela devrait être relativement facile à configurer.
vonbrand
Il s'agit d'un programme spécial (Isabelle) qui interprète déjà le code de manière quelque peu sûre (pas d'exécution de code arbitraire), mais permet toujours au code de créer des fichiers à des endroits arbitraires. Comme le code n'est pas fiable, je veux empêcher cela de se produire (en abandonnant le programme). Le programme fonctionne déjà en tant qu'utilisateur spécial, mais je me sentirais plus en sécurité si le code ne pouvait pas s'encombrer, par exemple, / tmp ou des endroits similaires.
Joachim Breitner
Vous pouvez ajouter un nouvel utilisateur pour exécuter l'application.
ctrl-alt-delor

Réponses:

9

Que diriez-vous de créer un chroot vide, puis de monter le système de fichiers principal en lecture seule à l'intérieur du chroot?

Devrait probablement être quelque chose comme ça pour créer un montage de liaison en lecture seule:

mount --bind /foo/ /path/to/chroot/
mount -o remount,ro /path/to/chroot/

Vous pouvez lier d'autres répertoires auxquels vous souhaitez que la prison ait également accès en écriture. Soyez prudent si vous avez besoin de monter des répertoires spéciaux (/ dev /, / proc /, / sys /), les monter tels quels peut être peu sûr.

Lie Ryan
la source
Encore une fois, a besoin de privilèges root et d'autres "configurations globales". Mais une option, oui.
Joachim Breitner
Est /foo/le chemin d'accès au système de fichiers principal?
Wayne Conrad
5

Il semble que le bon outil pour ce travail soit fseccompbasé sur le sync-ignoringcode f de Bastian Blank, j'ai trouvé ce fichier relativement petit qui empêche tous ses enfants d'ouvrir un fichier en écriture:

/*
 * Copyright (C) 2013 Joachim Breitner <[email protected]>
 *
 * Based on code Copyright (C) 2013 Bastian Blank <[email protected]>
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions are met:
 *
 * 1. Redistributions of source code must retain the above copyright notice, this
 *    list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright notice,
 *    this list of conditions and the following disclaimer in the documentation
 *    and/or other materials provided with the distribution.
 *
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
 * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
 * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR
 * ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
 * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
 * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
 * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
 * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
 * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */

#define _GNU_SOURCE 1
#include <errno.h>
#include <fcntl.h>
#include <seccomp.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

#define filter_rule_add(action, syscall, count, ...) \
  if (seccomp_rule_add(filter, action, syscall, count, ##__VA_ARGS__)) abort();

static int filter_init(void)
{
  scmp_filter_ctx filter;

  if (!(filter = seccomp_init(SCMP_ACT_ALLOW))) abort();
  if (seccomp_attr_set(filter, SCMP_FLTATR_CTL_NNP, 1)) abort();
  filter_rule_add(SCMP_ACT_ERRNO(EACCES), SCMP_SYS(open), 1, SCMP_A1(SCMP_CMP_MASKED_EQ, O_WRONLY, O_WRONLY));
  filter_rule_add(SCMP_ACT_ERRNO(EACCES), SCMP_SYS(open), 1, SCMP_A1(SCMP_CMP_MASKED_EQ, O_RDWR, O_RDWR));
  return seccomp_load(filter);
}

int main(__attribute__((unused)) int argc, char *argv[])
{
  if (argc <= 1)
  {
    fprintf(stderr, "usage: %s COMMAND [ARG]...\n", argv[0]);
    return 2;
  }

  if (filter_init())
  {
    fprintf(stderr, "%s: can't initialize seccomp filter\n", argv[0]);
    return 1;
  }

  execvp(argv[1], &argv[1]);

  if (errno == ENOENT)
  {
    fprintf(stderr, "%s: command not found: %s\n", argv[0], argv[1]);
    return 127;
  }

  fprintf(stderr, "%s: failed to execute: %s: %s\n", argv[0], argv[1], strerror(errno));
  return 1;
}

Ici, vous pouvez voir qu'il est toujours possible de lire des fichiers:

[jojo@kirk:1] Wed, der 06.03.2013 um 12:58 Uhr Keep Smiling :-)
> ls test
ls: cannot access test: No such file or directory
> echo foo > test
bash: test: Permission denied
> ls test
ls: cannot access test: No such file or directory
> touch test
touch: cannot touch 'test': Permission denied
> head -n 1 no-writes.c # reading still works
/*

Cela n'empêche pas de supprimer des fichiers, de les déplacer ou d'autres opérations de fichiers en plus de leur ouverture, mais cela pourrait être ajouté.

Un outil qui permet cela sans avoir à écrire du code C est syscall_limiter .

Joachim Breitner
la source
4
Notez que l'approche sécurisée consiste à mettre en liste blanche les appels système, et non à les mettre sur liste noire. Si trop est refusé, des assistants externes sans boîte peuvent être utilisés pour aider le programme. Avec LD_PRELOAD, ces assistants peuvent être rendus transparents pour le programme que nous exécutons.
Vi.
4

Envisageriez-vous d'écrire un substitut à la open(…)fonction et de le charger à l'aide de LD_PRELOAD?

Leonid
la source
2
Vous voulez probablement dire open... Eh bien, j'envisagerais d'utiliser une solution existante qui utilise cette approche, oui.
Joachim Breitner
2
Il y a quelque chose comme ça sur github.com/certik/restrict , mais il est configuré par compilation et ne semble pas être largement utilisé.
Joachim Breitner
Oui, désolé, mon erreur, mise à jour de la réponse… Mais il me semble que tu devras aussi en substituer un pour le write(…).
Leonid
En ce qui concerne github.com/certik/restrict , oui, vous avez tout à fait raison.
Leonid
3

La solution la plus simple est probablement un programme wrapper qui crée un nouvel espace de noms de système de fichiers avec les systèmes de fichiers appropriés montés en lecture seule, puis exécute le programme que vous essayez de restreindre.

C'est ce qui se systemdproduit lorsque vous utilisez ReadOnlyDirectories=pour marquer certains répertoires en lecture seule pour un service. Il existe également une unsharecommande util-linuxqui peut faire le travail de création d'un nouvel espace de noms, vous pouvez donc faire quelque chose comme:

unshare -m <wrapper>

où il wrappersuffirait alors de remonter les systèmes de fichiers comme requis avant de démarrer le vrai programme cible.

Le seul problème est que vous devez rootcréer le nouvel espace de noms ...

TomH
la source
J'y ai pensé. Mais est-ce possible sans être root? Existe-t-il un script / programme prêt à l'emploi pour cela?
Joachim Breitner
1
Oui, il semble que vous ayez besoin d'être root, au moins avec le noyau 3.7.
TomH
Je cherchais plus loin cette solution. Il est possible de lier récursivement le montage / à un nouveau /, mais pas et de le récursivement le marquer en lecture seule.
Joachim Breitner
2

Vous pouvez l'exécuter dans un chroot, monter des versions spéciales de /tmp et autres à l'intérieur. Peut-être que systemd est utile, et en particulier systemd-nspawn (1) , qui ressemble exactement à ce que vous voulez.

vonbrand
la source
2

Une machine virtuelle permettrait au script d'écrire n'importe où sans affecter le système hôte et d'inspecter où il essaie réellement d'écrire, ce qui semble être les objectifs.

Par exemple, vous pouvez facilement démarrer Arch Linux avec

kvm -boot d -m 512 -cdrom archlinux-*.iso
l0b0
la source
1
Je veux toujours exécuter le programme sur la machine actuelle pour éviter d'avoir à configurer un nouveau système, un nouvel environnement, etc. Une machine virtuelle est beaucoup trop lourde pour mon cas d'utilisation.
Joachim Breitner
2

Faire une configuration initiale en tant que root est vraiment le moyen le plus simple. Plus précisément, un chroot dans un montage de liaison en lecture seule est le chemin de moindre résistance.

Vous pouvez utiliser bindfs au lieu de mount --bindpour créer la vue en lecture seule sans avoir besoin d'être root. Cependant, vous devez faire quelque chose en tant que root pour empêcher l'accès à d'autres fichiers, tels que chroot.

Une autre approche consiste LD_PRELOADà utiliser une bibliothèque qui se connecte à l'ouverture de fichiers et refuse d'autoriser l'écriture. Cela ne nécessite aucun privilège spécial. Du point de vue de la sécurité, cela peut être contourné, mais c'est correct pour votre cas d'utilisation où vous n'avez besoin que de contenir une fonctionnalité spécifique et non du code natif arbitraire. Je ne connais pas de bibliothèque existante pour cela, cependant. LD_PRELOADpourrait également être utilisé pour limiter le programme à la vue en lecture seule créée avec mount --bindou bindfs; encore une fois, je ne connais pas de bibliothèque existante.

Sur Debian et ses dérivés, vous pouvez configurer un environnement schroot . Schroot est root setuid et doit être configuré en tant que root, mais peut être exécuté par n'importe quel utilisateur autorisé.

Une méthode qui ne nécessite aucune coopération de la part de root consiste à exécuter le processus sur une machine virtuelle. Vous pouvez configurer KVM ou VirtualBox, ou Linux en mode utilisateur . Il est un peu lourd et entraînera une consommation de mémoire supplémentaire, mais ne devrait pas affecter de manière significative la vitesse de calcul symbolique brut.

Comment «emprisonner» un processus sans être root? pourrait fournir une certaine inspiration.

Gilles 'SO- arrête d'être méchant'
la source
1

Une façon d'empêcher au moins le processus d'écrire les fichiers (mais pas de les créer) est d'appeler en ulimit -f 0premier. Cela interrompra le processus dès qu'il essaiera d'écrire dans un fichier, mais la création de fichiers vides est toujours possible.

Joachim Breitner
la source