An privilegierten Port binden geht nicht

K

Krull

Well-Known Member
Hallo,
ich möchte einen Nicht-root-Nutzer einen Port <1024 (hier 200) verwenden lassen. Dazu ist Folgendes eingestellt:
Bash: 
$ kldstat | grep mac                                    
 3    1 0xffffffff8271f000     4438 mac_portacl.ko

$ sysctl -a | grep security.mac                                      
kern.features.security_mac: 1
security.mac.portacl.rules: uid:1002:tcp:200
security.mac.portacl.port_high: 1023
security.mac.portacl.autoport_exempt: 1
security.mac.portacl.suser_exempt: 1
security.mac.portacl.enabled: 1
security.mac.mmap_revocation_via_cow: 0
security.mac.mmap_revocation: 1
security.mac.labeled: 0
security.mac.max_slots: 4
security.mac.version: 4

$ echo $UID       
1002

$ sockstat -46 -p 200 
USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS

$ nc -l 200
nc: Operation not permitted

Ich habe wohl etwas vergessen. Aber was?
 
Du musst zwingend dem System sagen, dass du Ports <1024 für User nutzbar machen willst (ACHTUNG! GEFÄHRLICH!), und dann den entsprechenden Port für die uid in der ACL "freischalten" (das hast du bereits gemacht)

Meines Erachten fehlt da nur noch

Code: 
 net.inet.ip.portrange.reservedlow=0

und

Code: 
net.inet.ip.portrange.reservedhigh=0

Ab da würd ich aber irgendwie schlechter schlafen...
 
turrican schrieb:
Du musst zwingend dem System sagen, dass du Ports <1024 für User nutzbar machen willst (ACHTUNG! GEFÄHRLICH!), und dann den entsprechenden Port für die uid in der ACL "freischalten" (das hast du bereits gemacht)

Meines Erachten fehlt da nur noch

Code: 
 net.inet.ip.portrange.reservedlow=0

und

Code: 
net.inet.ip.portrange.reservedhigh=0

Ab da würd ich aber irgendwie schlechter schlafen...
Zum Vergrößern anklicken....
Ja, das sagt man so. Aber sag mir genau wieso du da schlecht schlafen würdest? Agenommen das System ist voll unter deiner Kontrolle
 
ja, angenommen... nach der Änderung bleibt das ggf nicht mehr lang so :D

und die Unix-Urgötter werden sich beim erschaffen der 'priviledged ports' unterhalb 1024 und deren Zweck - und dass eben NICHT jeder daran Services binden kann - was gedacht haben...

Aber jeder darf es machen, wie er möchte, gell? Ich bin halt bei sowas da ein Schneeflöckchen...
 
@turrican "nach der Änderung bleibt das ggf nicht mehr lang so" wie soll man das verstehen? Wo ist der Unterschied ob ich einen angreifbaren Dienst auf "Port < 1024" oder "Port > 1024" laufen habe? Also abgesehen von der Situation wo sich zwei Services um einen Port "streiten" und crashen sehe ich da kein Problem, abgesehen davon das es zu Verwirrungen kommen kann wenn auf einmal ein Webserver auf Port 22 antwortet o.ä.

Unabhängig davon, sehe ich keinen Vorteil darin einen "priviledged port" (eher Nachteile), warum an den Systemeinstellungen rumspielen, wenn man einfachen einen höheren Port nehmen kann?
 
Hmm... prinzipiell haste natürlich recht; wenn man es genauer überlegt wenn ein $USER einen der unteren Ports binden darf, hätte der Angreifer eher sogar weniger Rechte (im Zweifel die des Users) als wie wenn der Service dahinter mit root Rechten liefe...

Aber ich denke, es geht in diesen Szenarien mehr um das "Vertrauen", dass hinter gewissen Ports gewisse "echte" bzw "authentische" Services laufen;
Dies kann man in diesem Szenario so nicht mehr feststellen - ob hinter einem Port 80 auch der "echte" Webserver läuft; wenn der z.B. eine Login-/Passwortabfrageseite anbietet, dann könnteste als User nicht sicher sein, ob dein Passwort wirklich beim Webserver zur Authentifizierung landet oder ob es nicht gleich einer mittels eigenem Service in ne Passwortliste abgreift...
 
turrican schrieb:
Aber ich denke, es geht in diesen Szenarien mehr um das "Vertrauen", dass hinter gewissen Ports gewisse "echte" bzw "authentische" Services laufen;
Dies kann man in diesem Szenario so nicht mehr feststellen - ob hinter einem Port 80 auch der "echte" Webserver läuft; wenn der z.B. eine Login-/Passwortabfrageseite anbietet, dann könnteste als User nicht sicher sein, ob dein Passwort wirklich beim Webserver zur Authentifizierung landet oder ob es nicht gleich einer mittels eigenem Service in ne Passwortliste abgreift...
Zum Vergrößern anklicken....
Also wenn da was mit http(s) antwortet ist es ein Webserver ;) Ob der verlässlich ist oder nicht hat aber nix damit zu tun ob der Service nun von der UID 0 oder einer anderen gestartet wurde. Wenn der Server von einer Person betrieben wird und keine andere Person Zugriff darauf hat kann der mit seinen Usern machen was er will und es wird für dich als Servicenutzer nicht anders. Ist es ein Server zu dem 20 Admins das root-passwort haben oder über sudo root-Rechte bekommen können muss du halt den 20 vertrauen. Ist ein System kompromittiert siehst du nicht ob root oder ein anderer User übernommen wurde. Geh mal davon aus, dass der root-Account geknackt sein könnte. Einem kompromittierten System kannst du eigentlich nie trauen, da es oft sehr schwer ist herauszufinden wie weit das geht.
Im Gegenzug dazu sollten wenige produktive Webserver nebenbei einen Useraccount für die komplette Belegschaft aufweisen. Das sollten eigentlich gehärtete Systeme sein.
 
Im Prinzip hast du völlig recht - aber wozu gibts dann noch privilegierte Ports?? Hätte man dann ja alle schon lang mit den Ports >1023 gleichstellen können, grade im Verbund mit Cloud und jeder HInz darf irgendwas administrieren, bzw jeder schreibt irgend nen Service für irgendwas :D

Wollte dem TE halt mit dem wenigen Wissen, was ich über das angefragte Thema hab, aushelfen - nur weil ich das nicht machen würde, heißt das nicht, dass der TE oder jemand anderes das ned machen darf :D
 
Man sollte auch bedenken, dass eigene Portnummern nicht mit /etc/services kollidieren sollten. Das koennte unter Umstaenden ungeahnte Sicherheitsluecken oeffnen.
 
Stimmt,
Bash: 
net.inet.ip.portrange.reservedlow=0
net.inet.ip.portrange.reservedhigh=0
hat bei mir noch gefehlt. Danke! Ich dachte, damit würden die reservierten Ports völlig freigegeben (wäre das nicht logisch?). Aber das scheint nicht der Fall zu sein.

Der Grund wieso ich das machen möchte ist Folgender: Hin und wieder läuft auf diesem Port eine Anwendung, die Daten von Außen entgegen nimmt. In pf ist der Port aber immer geöffnet (weil securelevel=3). Bisher müsste ich die Anwendung entweder mit Rootrechten starten oder einen hohen Port nehmen. Erstgenannte Lösung finde ich unschön. Letztere hat für mich den Nachteil, dass im wenn auch unwahrscheinlichen Fall einer Kompromittierung, z. B. durch verseuchte Drittsoftware, dieser Port dann für eine Hintertür o. ä. genutzt werden könnte, da er wie gesagt in der Firewall offen ist.

Vermutlich ist der Gewinn von dieser Seite aus tatsächlich nur minimal wenn überhaupt vorhanden. Aber dass ich auf der anderen Seite an Sicherheit verliere, kann ich noch nicht richtig nachvollziehen. Die betroffenen Rechner sind privat und werden ausschließlich von mir genutzt. Es wird also kein Dritter gutgläubig hinters Licht geführt :)
 
Sorry, dass ich diesen alten Thread hervorkrame.
Wozu benötige man mac_portacl, wenn ein simples "sysctl net.inet.ip.portrange.reservedhigh=0" offenbar auch genügt:
Code: 
$ id
uid=1002(zapata) gid=1002(zapata) groups=1002(zapata)
$ sysctl security.mac.portacl
sysctl: unknown oid 'security.mac.portacl'
$ sysctl net.inet.ip.portrange.reservedhigh
net.inet.ip.portrange.reservedhigh: 1023
$ nc -l 127.0.0.1 80
nc: Permission denied
$ sysctl net.inet.ip.portrange.reservedhigh
net.inet.ip.portrange.reservedhigh: 0
$ nc -l 127.0.0.1 80

$ sockstat -4 -p 80
USER     COMMAND    PID   FD  PROTO  LOCAL ADDRESS         FOREIGN ADDRESS     
zapata   nc           931 3   tcp4   127.0.0.1:80          *:*
Folgendes alleine funktioniert ja nicht:
Code: 
# kldload mac_portacl
# sysctl security.mac.portacl.rules="uid:1002:tcp:80"
$ nc -l 127.0.0.1 80
nc: Permission denied
 
Wie peinlich! :-( Ohne mac_portacl funktioniert es für alle; mit mac_portacl nur für die in den rules definierten uid/gids.
 
  • Like
Reaktionen: lme
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben