Newsgroup: it.comp.os.linux.sys
Titolo: abilitare i socket sotto 1024 agli utenti generici

ciao
vorrei riuscire ad abilitare agli utenti generici (nello specifico, un
utente) l'apertura dei listening socket sotto 1024, udp e tcp; preferisco
avere un utente ad hoc capace di aprire socket "bassi" piuttosto che un
programma setuid o lanciato da root....
mi potete dare una traccia? devo modificare qualcosa a livello di kernel?
grazie :-)
devnull
 
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 programma setuid o lanciato da root....
no posix ? no party !
-- 
Buttiglione filosofo?  E Platone cos'era, un metalmeccanico?
                -- Beppe Grillo

 problema, non la tua soluzione.
il problema nei suoi minimi termini è:
ho un software che deve girare con meno diritti possibile, essenzialmente
leggere e scrivere nella sua directory e poter aprire socket privilegiati
(per la precisione, 3, di cui 2 udp ed uno tcp)
non sono disposto a concedergli nulla di più, non deve girare con i diritti
di root in nessun momento, e comunque non deve poter fare nulla di più di un
utente normale se non aprire quei socket.
purtroppo non posso passargli io i socket già aperti, se li deve proprio
aprire lui. non posso neanche fare port forwarding credo, il protocollo è
... uhm .... "proprietario" 8-) e credo proprio che i numeri dei port siano
dentro il payload dei pacchetti...
dico anche qualcosa di più sul sistema, magari può essere utile: è
un'installazione "liscia" di fc4 (il kernel è quello di redhat, non l'ho
(ancora) sostituito con quello di 
kernel.org
); su questa posso installare
liberamente il software che ritieni necessario, e modificarla a piacere.
cosa suggerisci? mi bastano anche un paio di parole chiave selettive, poi
spulcio
grazie ancora
devnull
nero: ?


 (per la precisione, 3, di cui 2 udp ed uno tcp)
man capabilities
apt-get install compartment
man compartment
-- 
Chaos A.D.		|	Raging crowd
Tanks on the streets	|	Burning cars
Confronting police	|	Bloodshed starts
Bleeding the Plebs	|	Who'll be alive?

 situazione.
Il kernel linux supporta le capabilities dal 2.2.
E' possibile concedere ad un processo la CAP_NET_BIND_SERVICE
che consente di bindare socket sulle porte privilegiate.


 man capabilities
Very very interesting. Thanks, Wiplash.  :-)
bye G.L.

 nuovo?
Beh, diciamo che è un po' che linux insegue e persegue l'aderenza
agli standard POSIX.
Ovviamente, dal 2.2 ne è passata di acqua sotto i ponti e lo sforzo
profuso verso POSIX è stato notevole, nonostante tutto quel che si può
dire, anche con ragione, del 2.6

 man compartment
Leggendo il tuo articolo mi sono deciso a fare un po' di test sulle
capabilities.
Ho provato compartment visto che nella versione patchata-SuSE contiene la
chiamata a prctl per mantenere le capabilities dopo un setreuid(2).
Eppure:
# compartment --cap CAP_NET_BIND_SERVICE --user orlandi sh -c
'/sbin/getpcaps $$'
Warning: --user and --caps will not work together!
Capabilities for `14250': = cap_net_bind_service+i
Ciao,
-- 
Daniele Orlandi

 Capabilities for `14250': = cap_net_bind_service+i
Uhm...mai usato in prima persona, eppure mi avevano assicurato che
funziona.
Ora faccio anche io qualche test, a questo punto.
Ciao.


 Ciao.
Beh, c'è un discreto casino dietro, come c'era da aspettarsi.
http://colt.projectgamma.com/linux/capfaq.txt
è un'interessante lettura.
Sto ricompilando il kernel con CAP_PCAP abilitato, per cominciare.
Vediamo un po'...


 dentro il payload dei pacchetti...
Non c'entra: il port forward lo puoi fare comunque. A meno che tu non
ti sia dimenticato di dire qualcosa (es: porte aperte dinamicamente),
rimane una soluzione possibile, eventualmente in aggiunta a controlli
con il match owner.
Fabio

 Vediamo un po'...
In realtà dovrebbe essere possibile creare un wrapper anche senza
CAP_SETPCAP. E' l'implementazione di prctl che mi crea qualche dubbio.
Secondo me dovresti provare a usare compartment verificando che faccia prctl
Ciao,
-- 
Daniele Orlandi

 Secondo me dovresti provare a usare compartment verificando che faccia prctl
Infatti, ma ora vorrei capire a fondo il tutto: mi ha intrigato. :)


 Infatti, ma ora vorrei capire a fondo il tutto: mi ha intrigato. :)
mi devo scusare con tutti voi per essere sparito, sono stato fagocitato 
da altre cose ed in questi giorni non riesco neanche a leggere (cioè a 
leggerlo magari sì, per approfondirlo davvero mi ci vuole un pò più 
tempo ;-) ) questo interessantissimo thread.
vi ringrazio di nuovo sperando di metterlo a buon frutto al più presto
ciao, a presto
devnull

 > Infatti, ma ora vorrei capire a fondo il tutto: mi ha intrigato. :)
ciao,
ripesco questo thread (intanto che attendo di poter provare le posix
"capabilities", poco tempo e per altri motivi sto reinstallando fc4....) per
farvi un altro pò di oziose domande, NON ho particolari necessità in questo
caso, chiedo solo per curiosità, quindi... rispondete *sse* ne avete voglia
;-)
1. qualcuno di voi ha modo di usare in modo abbastanza regolare le ACL? se
sì come vi trovate? cosa ne pensate?
2. vado a memoria: mi pare che un pò di tempo fa ci fu un fiorire di user
file system (credo in particolare con la nascita del progetto lufs) e mi
ricordo vagamente che c'era anche un socketfs preliminare.... poi
personalmente non ne ho sentito più nulla; è effettivamente così o magari ha
cambiato nome?
3. a proposito di mappare i socket tcp/ip sul filesystem: iirc ksh mette a
disposizione una "simulazione" di questa funzionalità, ma non è messa a
disposizione di tutto il sistema, è proprio interna a ksh. altrove (credo in
una faq sulla bash, o nel man) ho letto una frase del tipo "per queste cose
è meglio non usare l'approccio di ksh ma invece usare netcat"
ok; ma ci sono particolari ostacoli dell'equiparare un'apertura di un socket
ad un'apertura di un file fittizio tipo "/...../ipv4/tcp/ipaddress/port" ?
è un problema di differenza "sostanziale" delle operazioni? oppure ad
esempio in un filesystem unix forse è obbligatorio implementare readdir (non
lo so, chiedo) e questo causa difficoltà?
al solito, anche indicare solo qualche parola chiave od un documento che
dovrei leggere sarebbe già moltissimo
ciao e grazie ancora se vi andrà di rispondere :-)
devnull
