/usr/bin/at bei daemon oder bei root??

[debiator]

Sorry, ich leg hier voll los

/usr/bin/at gehört bei mir dem daemon.

539254 56 -rwsr-sr-x 1 daemon daemon 55424 Sep 30 2014 /usr/bin/at

das ist doch irgendwie absurd oder warum nicht dem root??

[rendegast]

Der atd läuft als 'daemon',
zur Bedienung werden diese Rechte gebraucht.

Die eigentlichen jobs werden dann wohl von cron (root-Rechte) ausgeführt.

[debiator]

hmm... schon wieder was gelernt.. danke.
Dennoch ist es ja einwenig sicherheitskritisch oder nicht?

[MSfree]

hmm... schon wieder was gelernt.. danke.
Dennoch ist es ja einwenig sicherheitskritisch oder nicht?

at erzeugt Shellskripte, die unter /var/spool/cron/atjobs abgelegt werden. Dieses Verzeichnis darf nur vom Benutzer daemon beschrieben und gelesen werden, daher muß der Befehl at mit chown-daemon laufen.

Die jobs werden dann aber nicht von cron sondern von atd abgearbeitet. Sicherheitskritisch wäre es, wenn at nicht chown-daemon sondern chown-root wäre.

[Meillo]

@debiator: Hast du das suid-Bit gesehen?

So ein Setup ist notwendig, wenn verschiedene Nutzer kontrolliert in einen geschuetzen Bereich schreiben koennen sollen. Im konkreten Fall geht es um das Anlegen von At-Jobs.

Cron laeuft dann als root, damit er die einzelnen Jobs per setgid(2) jeweils als deren Besitzer ausfuehren kann.


EDIT: MSfree war schneller.

[Meillo]

Die jobs werden dann aber nicht von cron sondern von atd abgearbeitet.

Das ist implementierungsabhaengig. Oftmals ist es tatsaechlich cron(8), der die at-Jobs abarbeitet.

Sicherheitskritisch wäre es, wenn at nicht chown-daemon sondern chown-root wäre.

Auch das waere *nicht* sicherheitskritisch!



P.S.: Die Bezeichnung ``chown-root'' lese ich zum ersten Mal. Ueblicherweise wird dies ``suid-root'' oder ``setuid-root'' genannt. Ich bin mir aber nicht sicher, ob du wirklich das gleiche meinst wie ich. Der Besitzer eines Scriptes ist erstmal irrelevant solange man es ausfuehren darf. Relevant wird er nur, wenn das suid-Bit gesetzt ist.

[MSfree]

Sicherheitskritisch wäre es, wenn at nicht chown-daemon sondern chown-root wäre.

Auch das waere *nicht* sicherheitskritisch!

Naja, Programme, die mit suid-root (sorry für die Verwechselung) laufen und Dateien schreiben, sind potentiell immer gefährlich.

Man konnte das vor vielen Jahren mit vi ausnutzen. vi lief auf damaligen Unixen mit suid-root, um die Backupdateien in ein Verzeichnis schreiben zu dürfen, auf das der Nutzer nur Leserecht hatte. Blöderweise hatte das Backup ebenfalls suid-root, so daß man z.B. /bin/sh in den vi laden konnte, das wiederum hat eine Backupdatei mit suid-root erzeugt. Brach man vi ab, blieb das Backup stehen und, da es /bin/sh mit suid-root war, konnte man es aufrufen und hatte root-Zugang.

OK, das war ein Programmierfehler in vi, zeigt aber, daß suid-root potentiell gefährlich ist. Der heutige vi bzw. die Reimplementierung vim erzeugen das Backup im Arbeitsverzeichnis mit den Rechten des aktuellen Benutzers.

[Meillo]

Naja, Programme, die mit suid-root (sorry für die Verwechselung) laufen und Dateien schreiben, sind potentiell immer gefährlich.

Ja, so formuliert stimme ich dir zu.

Das Problem betrifft jede Art von suid- und sgid-Programm. Nur, bei root sind die moeglichen Auswirkungen eines Programmierfehlers halt die schlimmsten.

[catdog2]

Naja, Programme, die mit suid-root (sorry für die Verwechselung) laufen und Dateien schreiben, sind potentiell immer gefährlich.

Das ist potentiell sehr gefährlich ja und solche Programme sollten die Angriffsfläche möglichst gering halten und nur das was unbedingt nötig ist als uid 0 erledigen (z.B. Datei/Socket öffnen) und dann sofort wieder die Rechte weg werfen. Außerdem empfiehlt es sich soweit passend auf capabilities zu setzten um gar nicht erst zu viele Rechte vergeben zu müssen. z.B. ist für ping heute idr. nur CAP_NET_RAW gesetzt anstatt des suid bits.

[debiator]

ok, da verlässt mich meine Sachkenntnis

Hab mich erstmal durch suid-bit durchgelesen.
Da muss man die Architektur und die dazugehörigen Programme/Dienste wirklich sehr gut kennen, um zu begreifen, wo ein s gut ist und wo es nicht hingehört.