Echtes Jail in Liveconfig? Cronjob Info-Leak

Servercow · 4. September 2017

Hallo,

ich finde es schade, dass wir die Benutzer nicht via SSH richtig "jailen" können.

Die Cronjobs sind auch eher mau... erstelle ich einen Cronjob wie etwa `/bin/cp -r /etc/X/ /var/www/X/htdocs/`, kann ich mir schön Konfigurationsdateien ins Webroot kopieren. :-/

Ich bastel mir derzeit viele Lösungen selber, die gewisse Leaks unterbinden, aber es gibt immer neue Überraschungen. Gibt es da ein best practice?

kk · 4. September 2017

Das hat weniger mit LiveConfig zu tun, sondern ist vielmehr allgemein ein Problem mit Jail-Umgebungen.
Auch wenn man das mit Cronjobs in den Griff bekommt, die nächste Lücke wartet bestimmt. Etwa ein Bug in PHP, der open_basedir (mal wieder) umgehen lässt. Oder ein lokaler Kernel-Exploit, der einen Ausbruch aus der chroot-Umgebung erlaubt.
Grundsätzlich sollten Dateien in /etc/ (und nicht nur dort) so abgesichert sein, dass nur authorisierte Benutzer diese lesen dürfen. LiveConfig erzeugt (fast?) alle Konfigurationsdateien bewusst nicht "world-readable". Ich möchte sogar behaupten, dass es keine von LiveConfig erzeugte Datei in /etc/ gibt, die "sensible" Informationen enthält und die irgendein Web-User lesen darf (einzige Ausnahme: /etc/passwd).
SELinux wäre ein prima Ansatz, nur ist das leider so scharf dass ein "normales" Shared Hosting damit praktisch nicht möglich ist.
Eine andere Idee (quasi Weiterentwicklung von SSH-Jails) wäre das CageFS von CloudLinux (mehr dazu demnächst).

Zum aktuellen Cron-Thema: man kann in Crontabs über die Umgebungsvariable PATH= einstellen, mit welcher Shell die Prozesse ausgeführt werden. Eine erste Idee (ungetestet!) wäre, hier ein Wrapperscript festzulegen, welches die eigentliche Shell dann in der Jail des jeweiligen Kunden startet.
(sollte ja genügen, die Shell aus /etc/passwd auszulesen... warum macht Cron das eigentlich nicht selbst?)
Falls das hilft, wäre es für uns keine große Sache, die Erstellung der crontab-Datei entsprechend zu "patchen", damit LiveConfig die PATH=...-Angabe fest in jede Crontab einbaut.

Viele Grüße

-Klaus Keppler

Servercow · 4. September 2017

Das Thema jailed Shell ist wirklich leidig. Irgendeinen Ausweg gibt es fast immer, ich probiere da schon eine ganze Weile herum.

Ja, so einen Ansatz (SHELL=ein_wrapper) in den Crontabs verwende ich derzeit. Wäre super, wenn LC das automatisch reinhaut. Warum er nicht die Shell liest, verstehe ich auch nicht. Ich glaube, dass ich ihm auch nicht global die Shell mitgeben kann. Da ist crontab wohl doch sehr simpel gehalten.

Ihr habt doch eine Menge in LUA geschrieben (danke dafür), da kann ich bestimmt mal reinschauen gleich.

kk · 4. September 2017

/usr/lib/liveconfig/lua/cron.lua - in Zeile 48 müsste dann so etwas rein wie

Code

fh:write("SHELL=/usr/local/bin/jailshell.sh\n")

Wir werden dafür einfach eine Variable definieren, die man dann optional per custom.lua setzen kann.

Servercow · 5. September 2017

Super, danke.

Hier noch der Vollständigkeit halber mein alter LUA-Ansatz, um den Command zu filtern:

Code

local string = string


...


function in_allowed_binaries(list, val)
  for index, value in ipairs(list) do
    if value == val then
      return true
    end
  end
  return false
end


function split_cmd(inputstr)
  local t={} ; i=1
  for str in string.gmatch(inputstr, "([^%s]+)") do
    t[i] = str
    i = i + 1
  end
  return t
end


...


local allowed_binaries = { "dies", "das", "bla" }


...


local binary = {}
local binary = split_cmd(v['cmd'])
if binary[1] and in_allowed_binaries(allowed_binaries, binary[1]) then
   fuege_line_hinzu
end

Alles anzeigen

Falls sowas vllt. auch eingebaut werden sollte. Ist natürlich nicht ganz so toll, da keine Rückmeldung nach dem Hinzufügen gegeben wird, ob der Command nun drin ist. Man könnte den Command dann durch "mail dies_und_das" ersetzen, der dem User schreibt, dass der Command ungültig war.

Echtes Jail in Liveconfig? Cronjob Info-Leak

Jetzt mitmachen!

Benutzer online in diesem Thema