[FreeBSD/UNIX] Feedback omtrent opzetten van shares

[HyperBart]

Ik heb al een tijdje naar alle tevredenheid een NAS draaien op basis van ZFSguru... So far so good, ik ben er ondertussen wat bekend mee en hij draait "in productie".

Het enige nadeel op dit moment is het feit dat mijn shares niet zo goed zijn afgeschermd. In die zin dat shares publiekelijk/anonymous toegankelijk zijn... Ondertussen mijn kennis van UNIX permissies weer wat opgepoetst, te weten gekomen dat voor een folder te accessen je ook +x moet hebben enz...

Nu had ik graag het volgende "principe" opgezet:

2 entiteiten: Bart en "de rest".

De rest zijn gezinsleden, zoals mijn vriendin of vader of broer.

Het komt er op neer dat ik altijd en overal toegang moet tot hebben en nergens door gehinderd wil worden. De groep "rest" wil ik op bepaalde shares dezelfde rechten als mezelf geven, en op andere shares alleen lees en op nog andere shares geen toegang... Wel wil ik, dat alle files, door wie dan ook aangemaakt, dit schema ook volgen... Dwz, ook al maakt root een file of map aan, ik wil dat deze de bovenstaande constraints in acht neemt. Hoe ik dit doe op fileniveau heb ik nog niet door. Hoe ik dit bewerkstellig via Samba denk ik wel, en dat zou dan met het Samba create mask zijn...

Ik heb me ondertussen wat ingelezen in de sticky bit/GUID/SUID (begrijp ze nog niet volkomen, maar ik ben wel zover dat ik dit volgens mij niet nodig heb).

Nu zie ik eigenlijk door de bomen het bos niet meer en vroeg me af wat ik nu moet configureren:

Umask? sticky bit? Create mask? Security mask?

Of ik heb enkele principes niet door en haal dus nu alles door mekaar of ik ken de componenten nog niet goed genoeg om tot een oplossing te komen, in ieder geval had ik graag jullie oerduidelijk Nederlandse uitleg gehad en hierover een discussie gestart waarom ik voor een bepaald iets moet kiezen of net niet...

[MoleM]

in de smb.conf kun je per share ook opties toevoegen als "read list", "write list". Voor dezelfde shares kun jij jezelf natuurlijk "admin users" maken

[HyperBart]

Mja, ik heb daar nu wat verder over opgezocht, maar je permissies op OS-niveau moeten nog steeds juist staan...

Ik was eigenlijk aan het denken om mijn folders als volgende UGO in te stellen:

rwx rx ---
Bart Gezin Others

en voor bepaalde folders:

rwx rwx ---
Bart Gezin Others

maar ik vroeg me dan af, hoe zit dat met overerving? Ik wil dan dat als een gezinslid een file aanmaakt, dat die dezelfde permissies krijgt, hoe regel je dat af?

[FireDrunk]

Je moet ACL's implementeren.

Handleidingen genoeg. Wat je wil is namelijk automatisch meerdere groepen rechten geven. En dat is zonder ACL's nooit zo (altijd maar 1 owner, en 1 groep.)

Je zult heel ZFSguru's sharing systeem op de kop moeten zetten om dat voor elkaar te krijgen.
En dat is niet leuk, i know

[Voor 25% gewijzigd door FireDrunk op 06-12-2012 11:13]

[HyperBart]

Ondertussen ben ik onder Linux even aan het rommelen met ACL's, voor iets wat ik daar ook nodig heb (namelijk een directory in mijn home die beschrijfbaar moet zijn door Transmission, maar ook leesbaar voor mij) en ik heb volgend brouwsel:

bart@Pyro2:~/Downloads$ ls -la
total 40
drwxr-xr-x+  5 bart bart  4096 Dec 26 00:55 .
drwxr-xr-x  10 bart bart  4096 Dec 26 00:54 ..
drwxr-xr--   5 bart bart  4096 Dec 29 21:25 complete
drwxr-xr-x+  8 bart bart  4096 Dec 27 00:12 complete_bittorrent
-rwxr--r--   1 bart bart 12292 Dec 29 21:28 .DS_Store
drwxr-xr-x  50 bart bart  4096 Dec 29 21:25 incomplete
bart@Pyro2:~/Downloads$ getfacl complete_bittorrent/
# file: complete_bittorrent/
# owner: bart
# group: bart
user::rwx
user:debian-transmission:rwx    #effective:r-x
group::r-x
group:debian-transmission:rwx   #effective:r-x
mask::r-x
other::r-x
default:user::rwx
default:user:debian-transmission:rwx
default:group::r--
default:group:debian-transmission:rwx
default:mask::rwx
default:other::r-x

Het rare vind ik die "effective:r-x", hoe komt dat? Ik zie echt de fout daar niet mee in waardoor dat dat naar boven komt?

[FireDrunk]

Hmm, dat is inderdaad vreemd. Ik ken dat Effective niet.

Maar ik zal je uit een natte droom helpen. ZFS onder FreeBSD ondersteund niet deze vorm van ACL's.

Alleen NFSv4 ACL's worden ondersteund kwam ik achter. En die zijn heel anders.

Ik ga er zelf ook eens mee aan de slag.

[HyperBart]

Sidenote: dit is niet op ZFSguru, daarover ging ik nog wat buurten met jou (Skype niks online?) maar op Ubuntu, mijn downloadbak...

[Anoniem: 26306]

FireDrunk schreef op donderdag 06 december 2012 @ 11:11:
Je moet ACL's implementeren.

Nee hoor. Voor deze situatie is de setgid bit voldoende.

# Maak alle bestanden van de groep "gezin"
chgrp -v -R gezin /path/to/share
# Zet de setgid bit op alle directories
find /path/to/share -type d -exec chmod -v g+s '{}' ';'
# Op elke subdirectory die schrijfbaar moet zijn:
chmod -v g+w /path/to/share/subdir

Waarschuwing: dit werkt in elk geval op Linux, maar FreeBSD zou niet veel moeten afwijken op dit gebied.

[FireDrunk]

Dat is toch gewoon hetzelfde als

chown -R root:gezin /path

?

[Anoniem: 26306]

Totaal niet, waarom denk je dat?

[FireDrunk]

setgid == set group id?

[Raynman]

De setgid bit zorgt ervoor dat je niet elke keer opnieuw die chown/chgrp -R hoeft te runnen als er nieuwe bestanden aangemaakt worden.

Als ik het me goed herinner is dat echter het standaardgedrag onder FreeBSD; setgid is daar dan niet nodig, maar als het om Ubuntu gaat (downloadbak die hierboven ergens genoemd wordt) wel.

[FireDrunk]

Maar dan nu de hamvraag... Hoe zorg je ervoor dat Samba die groepen/permissies honoreert?

[ppl]

Wat setuid and setgid doen staat gewoon in de FreeBSD handbook:

The real user ID is the UID who owns or starts the process. The effective UID is the user ID the process runs as. As an example, the passwd(1) utility runs with the real user ID as the user changing their password; however, to manipulate the password database, it runs as the effective ID of the root user. This is what allows normal users to change their passwords without seeing a “Permission Denied” error.

The setgid permission performs the same function as the setuid permission; except that it alters the group settings. When an application or utility is ran with this setting, it will be granted the permissions based on the group that owns the file, not the user who started the process.

Hier moet je dus mee oppassen omdat het invloed heeft op je security. Ik zou ook eerder naar ACLs gaan omdat dit op een veel mooiere wijze de rechten definieert en dit in de toekomst wellicht ook handig kan zijn (bijv. als je een dir hebt waarbij bepaalde gezinsleden wel iets mogen en anderen weer niet; daar volstaat de groep "gezin" dus niet meer). Als je Samba gebruikt kun je ook op share niveau de rechten aanpassen. Beetje rondzoeken op internet gaf een handige link: ZFS and ACLs with Samba. Wat je nu wil doen kan al met de gewone rechten omdat je 1 user hebt en 1 groep en daar kun je prima rechten voor toewijzen zonder ACLs e.d. te hoeven gebruiken. In de Samba config definieer je voor de share de rechten waaronder ook de chmod (moet ie er chmod 655 van maken, of moet het 770 worden, etc.) voor wanneer een file of een dir wordt aangemaakt. Nixcraft heeft daar iets korts over. De rest is kwestie van de Samba manual raadplegen.

[Voor 9% gewijzigd door ppl op 05-01-2013 00:57]

[FireDrunk]

CiPHER zei dat ook al, dat je alle rechten in Samba kan regelen, maar is dat niet krom?
Je wil juist dat je filesystem de rechten regelt, en niet je applicatie.
Stel dat er een 0-day attack komt op Samba, die de security daar omzeilt, dan kan elke gebruiker gewoon in alle directories, omdat op filesystem niveau alles open staat?

Of zie ik nu beren op de weg...

( ik wil overigens hetzelfde implementeren als HyperBart, vandaar mijn interesse )

[ppl]

Waarom zou dat krom zijn? Je wil Samba gebruiken dus dan wil je ook via die weg regelen wat er op share niveau mogelijk is. Datzelfde doe je ook met diverse andere services op unix systemen zoals sudo, een ftp daemon, subversion server, een webserver, een database server, enz. Als je alles goed instelt dan kan Samba alleen binnen bepaalde dirs komen en alleen daar rechten aanpassen. Dat is eigenlijk ook de reden waarom je binnen een applicatie rechten wil bepalen. Je wil daar al beperkingen opleggen wie wat mag en kan. Dat filesystem is gewoon een volgende laag. Als je het echt veilig wil doen dan moet je denken aan Samba in een jail (de FreeBSD versie van een jail that is!) en dat soort zaken. Leuk om te doen maar hier wellicht pure overkill omdat het om een simpel servertje voor thuis gaat.

[FireDrunk]

Ik vind het er een beetje hetzelfde uit zien als zeggen: kernel en userland hoeven niet gescheiden te worden dmv security, dat doet de applicatie wel.

of,

Je hoeft geen lokale users te hebben, dat doen applicaties maar.

of,

Je hoeft (überhaupt) geen filesystem permissies te hebben, want applicaties houden dat zelf maar bij.

Natuurlijk zwaar gechargeerd, maar you get the point.

Ik ben van mening dat je security zo dicht mogelijk bij de bron moet doen, en niet later.

Bovendien hoef je als je goede filesystem permissies hebt, samba helemaal niets te laten doen in mijn ogen, Samba moet gewoon de filesystem permissies volgen dan. Net als FTP, SSH en alle anderen dan ook moeten.

[Raynman]

ppl schreef op zaterdag 05 januari 2013 @ 00:54:
Wat setuid and setgid doen staat gewoon in de FreeBSD handbook:

[...]

[...]

Hier moet je dus mee oppassen omdat het invloed heeft op je security.

Dat is niet bepaald relevant; dat gaat over setgid voor executables. (Wikipedia: setuid/setgid on directories) In mindere mate geldt dat ook voor de rest van je post over ACL's: TS wil onderscheid maken tussen Bart en de rest van Gezin. Dat kan prima met standaard UNIX-rechten en setgid bit. Voor complexere scenario's zul je wel naar ACL's moeten kijken.

FireDrunk schreef op vrijdag 04 januari 2013 @ 15:08:
Maar dan nu de hamvraag... Hoe zorg je ervoor dat Samba die groepen/permissies honoreert?

In je eigen woorden:

FireDrunk schreef op zaterdag 05 januari 2013 @ 16:11:
Bovendien hoef je als je goede filesystem permissies hebt, samba helemaal niets te laten doen in mijn ogen, Samba moet gewoon de filesystem permissies volgen dan. Net als FTP, SSH en alle anderen dan ook moeten.

Alleen create/directory mask moet je nog wel goed zetten in smb.conf (create: 0764 ipv 0744 (default), dir: 0775 ipv 0755, of laatste cijfer lager om rechten voor others te beperken), om nieuwe bestanden ook schrijfbaar te maken voor Gezin (of niet, als iedereen elkaars bestanden wel mag zien, maar niet wijzigen, wat je krijgt zonder masks aan te passen).

NB: wat de user van nieuwe bestanden wordt, is nog wel afhankelijk van samba-instellingen (neem je één guest user of krijgt elk gezinslid zijn eigen user) en het zal waarschijnlijk niet Bart zijn, maar ik neem aan dat Bart ook een lid van Gezin is, dus dan kan Bart ook gewoon bij die bestanden.

[ppl]

Raynman schreef op zaterdag 05 januari 2013 @ 21:50:
Dat is niet bepaald relevant; dat gaat over setgid voor executables. (Wikipedia: setuid/setgid on directories)

Uit de pagina van het handbook waar ik naar refereerde:

The first two special permission bits we discussed (the setuid and setgid permission bits) may lower system security, by allowing for elevated permissions. There is a third special permission bit that can strengthen the security of a system: the sticky bit.

Dat is wat duidelijker hierover en had ik wellicht ook moeten citeren. Al met al moet men er ook niet zwaar aan trekken. Vooral in een thuisomgeving zal het weinig uitmaken.

FYI: ZFSguru is gewoon FreeBSD met wat opschmuck en dus is het FreeBSD handbook gewoon van toepassing, vandaar ook de verwijzing.

In mindere mate geldt dat ook voor de rest van je post over ACL's: TS wil onderscheid maken tussen Bart en de rest van Gezin. Dat kan prima met standaard UNIX-rechten en setgid bit. Voor complexere scenario's zul je wel naar ACL's moeten kijken.

Precies. Met het oog op de toekomst zijn ACLs wat handiger en ze worden inmiddels al veelvuldig gebruikt (OS X en Windows werken daar al standaard mee waarvan Windows al een jaar of 10). Een ander voordeel is dat rechten ook wel wat inzichtelijker worden. Het is duidelijker te zien wie wat mag/kan dan iets als rwsr--r-- om maar eens wat te noemen. Er leiden meer wegen naar Rome dus kies vooral je eigen weg

FireDrunk schreef op zaterdag 05 januari 2013 @ 16:11:
Ik vind het er een beetje hetzelfde uit zien als zeggen: kernel en userland hoeven niet gescheiden te worden dmv security, dat doet de applicatie wel.

Dan heb je het niet begrepen. Even uitleggen aan de hand van een citaat van jou:

Stel dat er een 0-day attack komt op Samba, die de security daar omzeilt, dan kan elke gebruiker gewoon in alle directories, omdat op filesystem niveau alles open staat?

Dat is de reden waarom je het gelaagd wil doen. Liever op 2 plekken die settings dan op 1. Als je alleen maar op de filesystem settings af gaat heb je maar 1 laag waar ze doorheen hoeven te prikken. Voor thuis is dat niet erg maar als je het in een grote omgeving zoals dat van een universiteit wil gebruiken wordt het een heel wat groter probleem. Daarom draai je applicaties ook niet als root, zorg je dat users niet bij alle services kunnen en alle rechten hebben, etc. etc. etc. Om eens een ander voorbeeld te geven: wat doe je als je niet wil dat bepaalde shares zichtbaar zijn voor alle users? Of wat nou als je niet wil dat users alle homedirs zien maar alleen hun eigen? Dat kun je niet allemaal regelen op het filesystem, dat moet je in Samba. Niet alles is op te lossen door rechten op het filesystem net zo min als in Samba.

[FireDrunk]

Ok, maar waar licht dan de gulden middenweg? Want 100% samba is dan niet de optie, maar 100% filesystem ook niet.

Een van de dingen die ik vaak mis, is dat files door samba met de goede owners worden aangemaakt.

Hier word alles vanzelf van ofwel root of share (in het geval van ZFSguru).

[ppl]

In dit geval is er geen gulden middenweg. Je zult het op beide plekken moeten instellen.