Ubuntu/nextcloud - Doe ik dit een beetje fatsoenlijk?

[World Citizen]

_{Met het risico dat ik wellicht echt te weinig kennis heb en me hier nog niet dien te melden, wil ik het toch vragen. Schiet me af als ik domme vragen stel, daar heb ik iets aan, want dan weet ik ook dat ik het niet goed doe.}

---

Ik ben mijzelf aan het verdiepen in een local cloud oplossing. Mijn doel is om een VM op te zetten en daar Nextcloud in te draaien.
Dit wil ik het liefst helemaal zelf opbouwen dus geen gebruik maken van Snaps ed.

Na een week rotzooien heb ik een idee en opzet van wat ik denk te moeten doen, en hier zou ik graag jullie feedback op willen.
Ik ben niet op zoek naar hoe het precies moet, maar meer of mijn theorie klopt en het systeem straks fatsoenlijk en enigszins best-practice is gebouwd.

Ik zit alleen een beetje in mijn maag met de manier waarop ik rechten ga uitdelen op functies en locaties.

Ik wil:
- VM met Ubuntu
- Datastore mounten in /mnt/store001 (dus niet in ~/media/admnistrator)
- Users aanmaken die enkel in een bepaalde folder van die mount kunnen (ofwel /mnt/store001/username)
- Apache installeren onder Administrator
- Sql/MariaDB (twijfel nog) installeren onder Administrator
- Nextcloud installeren als administrator met datastore uit /mnt/store001
- Nextcloud user rechten geven op hen eigen folder (dus niet op de hele /mnt/store001/)
-

Ik heb te weinig kennis om in te schatten of dit een beetje een fatsoenlijk manier is. Zoals ik het begrijp draait in bovenstaande voorbeeld
- Het systeem onder Sudo,
- Apache en Nextcloud en SQL/ Mariadb onder Adminstrator,
- En kunnen users enkel onder hun eigen folder werken

Daarnaast wil ik de hele /mnt/store001 locatie via samba sharen onder een Administrator user zodat ik vanuit andere machines beveiligd onderhoud kan doen.

Kan iemand wat feedback geven over mijn user beveiliging en of bv /mnt de juiste locatie is om dit te doen. (ik kan niet goed vinden of /mnt hier echt voor bedoeld is)
Zie ik iets ove rhet hoofd, of is wellicht mijn hele filesofie niet in orde?
Het is maar een thuis oplossing en voorlopig is er welgeteld 1 user 😊, maar ik wil het graag een beetje snappen. Ik kan wel alles onder Admin/Su doen... maar zo moet het niet.

Alvast bedankt.

[JDV808]

Je hebt goed je research gedaan zie ik. Zelf heb ik bij de eerste keer ook de vm minimaal 2 keer weggegooid. Het beste is proberen, maar als ik het me herinner dan zit je op deze manier wel goed.

[Room42]

Wat bedoel je met de user 'Administrator'? Is dat een user die je zelf aan gaat maken? Of bedoel je 'root'? In dat geval moet je dat even heroverwegen. In principe draait er zo min mogelijk als 'root'. Je kunt beter een normale gebruiker maken voor dat soort zaken. Het liefst zelfs een zonder sudo-rechten.

Overigens, als je onder Ubuntu gewoon 'sudo apt install apache2' draait, wordt er automatisch een gebruiker en groep 'www-data' aangemaakt. Dit is een prima user om mee te werken.

Nog wat steekwoorden, op basis van jouw tekst:
/mnt/store001 is een prima map. Je moet wel even de juiste permissies zetten.

Het usermanagement van Nextcloud staat los van de linux-users. Alles draait gewoon onder de user van de webserver.

Ik zou kiezen voor MariaDB, die heeft momenteel een betere compatibiliteit dan MS SQL.

Software installeren op Linux gaat altijd als root, dan wel via 'sudo'. Doe maar eens 'sudo whoami'

[ Voor 31% gewijzigd door Room42 op 29-03-2019 11:02 ]

[HKLM_]

Vergeet ook niet je nextcloud/server te beveiligen als je hem naar buiten open zet.

[ Voor 4% gewijzigd door HKLM_ op 29-03-2019 11:13 ]

[World Citizen]

JDV808 schreef op vrijdag 29 maart 2019 @ 10:52:
Je hebt goed je research gedaan zie ik. Zelf heb ik bij de eerste keer ook de vm minimaal 2 keer weggegooid. Het beste is proberen, maar als ik het me herinner dan zit je op deze manier wel goed.

2x ?

Room42 schreef op vrijdag 29 maart 2019 @ 10:57:
Wat bedoel je met de user 'Administrator'? Is dat een user die je zelf aan gaat maken? Of bedoel je 'root'? In dat geval moet je dat even heroverwegen. In principe draait er zo min mogelijk als 'root'. Je kunt beter een normale gebruiker maken voor dat soort zaken. Het liefst zelfs een zonder sudo-rechten.

Grijs gebied hier , want daar snap ik iets niet denk ik.
Zoals ik het begrijp
Je hebt standaard de Root user SUDO
Je hebt de user die je aanmaakt tijdens install Administrator
Je maakt extra users aan als gebruikers

Ik dacht dat het systeem draait onder SU, dat je processen laat starten onder Administrator en dat je werkt onder een lage user. Als je systeem onderhoud doet log je in als Adminsitrator en waar nodig elevate je naar SU. Je doet nooit iets direct als SU user. Ik zou dan de Administrator User ook uitkleden zodat hij niet zo veel kan als SU, maar wel bijna alles kan.

Zo werk ik dus standaard als een user. Als ik Nextcloud/Apache/SQl wil onderhouden doe ik dat als Administrator, en als ik Core-Ubuntu werkt doe, elevate ik Administrator naar SU.

Overigens, als je onder Ubuntu gewoon 'sudo apt install apache2' draait, wordt er automatisch een gebruiker en groep 'www-data' aangemaakt. Dit is een prima user om mee te werken.

Dat moet ik gaan lezen. Want ik wilde dus eigenlijk een systeem-wide administrator account om dit te doen. Dus de Apache al laten installeren/opstarten onder unix bekende Administrator account.

Mijn idee was dat Administrator software processen als Apache/SQL/Nextcloud afhandeld, maar niet zonder elevation naar systeemtaken kan.

Nog wat steekwoorden, op basis van jouw tekst:
/mnt/store001 is een prima map. Je moet wel even de juiste permissies zetten.

Check, dit zag ik als voordeel. Dus rechten toewijzen waar nodig is, zodat niet iedereen overal in kan.

Het usermanagement van Nextcloud staat los van de linux-users. Alles draait gewoon onder de user van de webserver.

Ja check, Dus apache draaien onder Administrator waardoor het Nextcloud proces ook als Administrator draait. Nextcloud usermanagement regelt dan dat Nextcloud users in hen eigen mappen mogen, maar op Ubuntu niveau clone ik die users zodat ze ook buiten Nextcloud om in die folder kunnen.

Ik zou kiezen voor MariaDB, die heeft momenteel een betere compatibiliteit dan MS SQL.

Software installeren op Linux gaat altijd als root, dan wel via 'sudo'. Doe maar eens 'sudo whoami'

Ja volgens mij snap ik dat. Ik installeer het onder SU, maar wil het proces uiteindelijk draaien onder Administrator.


Als ik het geod begrijp gaat mijn Administrator user niet gek veel andere rechten krijgen dan SU, maar ik voor mijn gevoel heb ik liever een SysteemProces users als Administrator dan dat ik het allemaal met SU doe.

HKLM_ schreef op vrijdag 29 maart 2019 @ 11:13:
Vergeet ook niet je nextcloud/server te beveiligen als je hem naar buiten open zet.

Ja goed punt. Want door dus Nextcloud als Administrator te laten uitvoeren en niet als SU, hoop ik dus die administrator user uit te kunnen kleden dat hij dit wel doet, maar niet bij Core-System kan zonder elevation.
Nextcloud/apache/sql start dan als Administrator.


maar wellicht krijg ik nu de indruk van jullie dat ik het verkeerd begrijp en SU eigenlijk hetzelfde gaat zijn als Administrator. Wellicht is mijn idee om Administrator iets of wat uit te kleden niet kloppend?


Bij Windows draai ik services ook altijd onder dedicated users die enkel geschikt zijn voor die services. Ik draai zelden iets onder CurrentUser of Adminsitrator of System. Ik probeer altijd een extra user aan te maken per functie.

[Room42]

World Citizen schreef op vrijdag 29 maart 2019 @ 11:35:
[...]
Je hebt standaard de Root user SUDO
Je hebt de user die je aanmaakt tijdens install Administrator
Je maakt extra users aan als gebruikers

Nee, nee. Je hebt de user 'root'. Deze user oppermachtig op het lokale systeem. Hier zijn ook geen rechten van te ontnemen. Daarom is het over het algemeen geen goed idee om onder die rechten te werken voor normale activiteiten. Je maakt dus bij de installatie een standaardgebruiker aan. Jij noemt die blijkbaar Administrator. Ik noem hem meestal mijn voornaam voor eigen servers of 'supervisor' voor onze zakelijke installaties.

Deze eerste user heeft standaard sudo-rechten. Sudo is een programma dat je tijdelijk root-rechten geeft. 'sudo whoami' laat zien dat je op dat moment even 'root' bent. Als je gewoon 'whoami' doet, krijg je je eigen gebruikersnaam.

Ik dacht dat het systeem draait onder SU, dat je processen laat starten onder Administrator en dat je werkt onder een lage user. Als je systeem onderhoud doet log je in als Adminsitrator en waar nodig elevate je naar SU. Je doet nooit iets direct als SU user. Ik zou dan de Administrator User ook uitkleden zodat hij niet zo veel kan als SU, maar wel bijna alles kan.

Zo werk ik dus standaard als een user. Als ik Nextcloud/Apache/SQl wil onderhouden doe ik dat als Administrator, en als ik Core-Ubuntu werkt doe, elevate ik Administrator naar SU.

su is ook een programma om zaken als root uit te voeren, maar dan heb je het root-wachtwoord nodig. Met 'su' log je in als root. Maar deze is meestal uitgeschakeld.

Daarnaast heb je ook nog een relatie tussen Apache, PHP en 'su'. Deze relatie maakt dat PHP wordt uitgevoerd als de opgegeven gebruiker, dus bijvoorbeeld een normale gebruiker in zijn eigen home directory. Dat wordt meestal gebruikt voor shared hosting, waarbij er meerdere websites op een host draaien die niks met elkaar te maken mogen hebben.

[...]

Dat moet ik gaan lezen. Want ik wilde dus eigenlijk een systeem-wide administrator account om dit te doen. Dus de Apache al laten installeren/opstarten onder unix bekende Administrator account.

Mijn idee was dat Administrator software processen als Apache/SQL/Nextcloud afhandeld, maar niet zonder elevation naar systeemtaken kan.

Voor de volledigheid: Apache zal standaard als 'root' draaien. Maar deze "forkt" (start) subprocessen onder de gebruiker met beperkte rechten (www-data, of welke gebruiker je ook maar opgeeft). Elke bezoeker krijgt zijn eigen proces! Ik denk dat je de term "Administrator" even moet laten varen, want dat is een Windows-term.

[...]

Check, dit zag ik als voordeel. Dus rechten toewijzen waar nodig is, zodat niet iedereen overal in kan.

Ja, alleen is er bijna geen 'iedereen'. De meest gevoelige gebruiker, die van de webserver, zal toch toegang moeten hebben omdat je anders geen Nextcloud kunt draaien Nextcloud is de enige buffer tussen het internet en de data op de disk.

Ja check, Dus apache draaien onder Administrator waardoor het Nextcloud proces ook als Administrator draait. Nextcloud usermanagement regelt dan dat Nextcloud users in hen eigen mappen mogen, maar op Ubuntu niveau clone ik die users zodat ze ook buiten Nextcloud om in die folder kunnen.

Ik weet niet precies wat je hier bedoelt. Ubuntu-gebruikers hebben standaard niks met Nextcloud-gebruikers te maken. Nextcloud draait op Apache/PHP. Als je PHP als Apache-module draait, draait Nextcloud dus standaard als de gebruiker 'www-data'. Binnen Nextcloud definieer je gebruikers. Deze gebruikers worden opgeslagen in de database. Nextcloud controleert steeds in de database of een gebruiker toegang mag krijgen tot een bestand of niet.


Verder heb ik even geen tijd meer... zal wellicht straks verder reageren

[amx]

Je zorgen om toegangsrechten ontgaan me een beetje. Je werkt zeg je in een VM. Waarom? En in het verlengde daarvan: Waarom dan geen snap of (kan ook) container?

[World Citizen]

Room42 schreef op vrijdag 29 maart 2019 @ 11:52:
[...]

Nee, nee. Je hebt de user 'root'. Deze user oppermachtig op het lokale systeem. Hier zijn ook geen rechten van te ontnemen. Daarom is het over het algemeen geen goed idee om onder die rechten te werken voor normale activiteiten. Je maakt dus bij de installatie een standaardgebruiker aan. Jij noemt die blijkbaar Administrator. Ik noem hem meestal mijn voornaam voor eigen servers of 'supervisor' voor onze zakelijke installaties.

Deze eerste user heeft standaard sudo-rechten. Sudo is een programma dat je tijdelijk root-rechten geeft. 'sudo whoami' laat zien dat je op dat moment even 'root' bent. Als je gewoon 'whoami' doet, krijg je je eigen gebruikersnaam.

[...]

su is ook een programma om zaken als root uit te voeren, maar dan heb je het root-wachtwoord nodig. Met 'su' log je in als root. Maar deze is meestal uitgeschakeld.

Wat mis ik hier dan? Je hebt de ROOT user, en je hebt de user die je aanmaakt bij install. Die laatste MAG ook root uitvoeren als je hem daartoe opdracht geeft middels SU.

Ik noem die inderdaad Administrator, omdat hij dus meer mag (elevaten naar Root) dan een standaard gebruiker die straks dus enkel gebruiker is.

Ik heb dus:
Root - Mag alles
Administrator - Mag heel veel, en zou eventueel Root rechten kunnen krijgen
World Citizen - Mag weinig en kan enkel gebruik maken van het systeem (kan ook geen root rechten krijgen)

Root - Doet Ubuntu Core
Administrator - Doet services processen in de runtime beheren/opstarten (evt elevated als Root)
Word Citizen - Doet enkel gebruik maken van programma's

Daarnaast heb je ook nog een relatie tussen Apache, PHP en 'su'. Deze relatie maakt dat PHP wordt uitgevoerd als de opgegeven gebruiker, dus bijvoorbeeld een normale gebruiker in zijn eigen home directory. Dat wordt meestal gebruikt voor shared hosting, waarbij er meerdere websites op een host draaien die niks met elkaar te maken mogen hebben.

[...]

Voor de volledigheid: Apache zal standaard als 'root' draaien. Maar deze "forkt" (start) subprocessen onder de gebruiker met beperkte rechten (www-data, of welke gebruiker je ook maar opgeeft). Elke bezoeker krijgt zijn eigen proces! Ik denk dat je de term "Administrator" even moet laten varen, want dat is een Windows-term.

Hmm.. dus Apache start altijd onder Root? Ik kan die niet starten onder een Administrator die eventueel dingen als Root kan uitvoeren, maar dat niet kan zonder elevation?

Moet ik Apache systeem processen altijd onder Root doen?

Ja, alleen is er bijna geen 'iedereen'. De meest gevoelige gebruiker, die van de webserver, zal toch toegang moeten hebben omdat je anders geen Nextcloud kunt draaien Nextcloud is de enige buffer tussen het internet en de data op de disk.


Ik weet niet precies wat je hier bedoelt. Ubuntu-gebruikers hebben standaard niks met Nextcloud-gebruikers te maken. Nextcloud draait op Apache/PHP. Als je PHP als Apache-module draait, draait Nextcloud dus standaard als de gebruiker 'www-data'. Binnen Nextcloud definieer je gebruikers. Deze gebruikers worden opgeslagen in de database. Nextcloud controleert steeds in de database of een gebruiker toegang mag krijgen tot een bestand of niet.


Verder heb ik even geen tijd meer... zal wellicht straks verder reageren

Oke. Maar die gevoelige gebruiker moet perse Root zijn? En mag dus niet een ander account zijn wat kan elevaten? Ik snap dat Nextcloud een eigen userdatabase heeft, maar ik zou daar gewoon dezelfde users aanmaken als dat ik in Ubuntu doe. Dus je hebt een Nextcloud user WorldCitizen en ook een Ubuntu User WorldCitizen. Beide users hebben rechten op die locatie waar de Cloud bestanden staan. Zo kun je dus via Nextcloud en via Ubuntu/samba bij je bestanden.


Dankjewel voor je tijd @Room42 Waardeer ik enorm! Ik voel me nog iets te veel rondzwemmen om zekerheid te hebben.

amx schreef op vrijdag 29 maart 2019 @ 13:14:
Je zorgen om toegangsrechten ontgaan me een beetje. Je werkt zeg je in een VM. Waarom? En in het verlengde daarvan: Waarom dan geen snap of (kan ook) container?

Nou, ik wil liever alles dichtzetten en dan deuren openen waar dat moet, dan dat ik straks perrongelijk een hele store naar Internet openzet. Noem het paranoia..
Ik werk in een VM omdat ik een host over had die krachtig genoeg is om dit op te draaien en daarnaast nog wat ander spul.
Ik had een snap 100% werkend, maar dan krijg je bijvoorbeeld je Apache in je snap. En als je dan iets daarnaast wil laten draaien dan moet je weer een 2e apache.. met relay....

Dat vind ik rotzooierig. Ik wil dan liever netjes 1 apache die met VirtualHosts ed de verschillende functies als een website/cloud/ftp of wat dan ook aanbied.

Liever meer beheer dan gemak zeg maar.

[ Voor 10% gewijzigd door World Citizen op 29-03-2019 13:55 ]

[Room42]

@World Citizen Ik denk dat je iets teveel met een Windows-bril naar het geheel kijkt Ik wil adviseren even wat documentatie of Youtube-videos te kijken over hoe het Linux gebruikers-, rechten en processensysteem werkt. Dat komt misschien iets samenhangender over dan hoe ik het vertel

Daarnaast zou ik eens een standaard Ubuntu LAMP-server installeren en dan gewoon kijken hoe dat in elkaar zit. Dit is een mooie start: https://www.digitalocean....p-lamp-stack-ubuntu-18-04

[World Citizen]

Room42 schreef op vrijdag 29 maart 2019 @ 13:58:
@World Citizen Ik denk dat je iets teveel met een Windows-bril naar het geheel kijkt Ik wil adviseren even wat documentatie of Youtube-videos te kijken over hoe het Linux gebruikers-, rechten en processensysteem werkt. Dat komt misschien iets samenhangender over dan hoe ik het vertel

Daarnaast zou ik eens een standaard Ubuntu LAMP-server installeren en dan gewoon kijken hoe dat in elkaar zit. Dit is een mooie start: https://www.digitalocean....p-lamp-stack-ubuntu-18-04

Laat ik dat dan als beste antwoord markeren

Ik ga nog even verder lezen.

[amx]

Nou, ik wil liever alles dichtzetten en dan deuren openen waar dat moet, dan dat ik straks perrongelijk een hele store naar Internet openzet. Noem het paranoia..
Ik werk in een VM omdat ik een host over had die krachtig genoeg is om dit op te draaien en daarnaast nog wat ander spul.

niet mijn vraag, maar oké, ook niet iets waar ik bij mijn installatie op zit te wachten.

Ik had een snap 100% werkend, maar dan krijg je bijvoorbeeld je Apache in je snap. En als je dan iets daarnaast wil laten draaien dan moet je weer een 2e apache.. met relay....

Dat vind ik rotzooierig. Ik wil dan liever netjes 1 apache die met VirtualHosts ed de verschillende functies als een website/cloud/ftp of wat dan ook aanbied.

Liever meer beheer dan gemak zeg maar.

Grappig. Ik had aanvankelijk Nextcloud in een LXD container draaien en had daarin de snap in geinstalleerd. Noem het paranoia... Ik heb uiteindelijk gekozen voor liever wat meer gemak en minder beheer. Het "relay" probleem heb ik afgevangen met een url-rewrite regel in lighttpd.

Veel succes in ieder geval!

[CAPSLOCK2000]

Nextcloud heeft inderdaad z'n eigen user-database. Daar weet het systeem niks van, vanuit het systeem gezien draait heel Nextcloud als één gebruiker. Dat kan een gewone gebruiker zijn zonder geavanceerde rechten.

Ik sluit me aan bij het advies om eerst een "generieke" LAMP-server op te zetten en dan daarna Nextcloud toe te voegen, dan is waarschijnlijk beter duidelijk hoe de componenten samen hangen.

[World Citizen]

Die LAMP tutorials snap ik. Eentje uitgevoerd en dat ging goed, maar daardoor kreeg ik vragen.

Apache word constant als www-data uitgevoerd. maar dat geld dan voor elke site straks. Users die via www-data straks iet mogen doen in een site, kunnen dan automatisch ook in andere sites.

Om nou te voorkomen dat 1 site de rest ook open zet wil ik apache en al het onderliggende dus niet onder www-data draaien. Althans, de sites moeten restricted zijn tot hen site en niet alle andere sites.

Hypotetisch:
Maatje vraagt of hij bij mij een site mag hosten... en voor een kratje bier mag dat natuurlijk. Maar ik wil niet dat hij met zijn rechten mijn site kan aanpassen. Hij moet dus niet lid zijn van www-data, als die groep ook rechten heeft op alle andere sites.

Al die tutorials gaan daar niet op in. Die starten allemaal alles onder www-data, en dan gaan ze aan het bier

Ik moet daar toch iets van beheer op kunnen doen en kunnen afknijpen.

Ik zat net met iemand te kletsen en die bevestigd wel mijn hele idee. Hij zegt ook dat je voor elke applicatie/service een eigen user moet maken, en dat je die user rechten moet geven op bestanden/mappen van andere applicaties waar hij op leunt. Dus als PHP en Apache een bestand van elkaar nodig hebben, dan geef je de respectievelijke user rechten op dat ene bestand. Danwel enkel lezen, of meer rechten.

Dit is een berg werk, ik weet het, maar ik geef liever expliciet rechten dan dat ik groepen ga maken die globaal dingen kunnen. Apache en PHP hebben niet ALLE bestanden van elkaar nodig.

[CAPSLOCK2000]

Je stelt de juiste vragen, fijn

Er zijn verschillende oplossingen mogelijk, maar ik beperk me nu even tot de beste/populairste.
Ten eerste maken we een splitsing tussen files voor Apache en files voor PHP, ten tweede maken we een splitsing per gebruiker. We gebruiken FPM als proces manager voor PHP en maken daar gebruik van om PHP onder een (of meer) aparte gebruikers te laten draaien.

Apache hoeft files typisch alleen maar in te lezen en heeft geen schrijfrechten nodig.
We geven Apache dus leesrechten op alle statische files van alle gebruikers.
De eenvoudige oplossing is om daar de groep www-data voor de gebruiken maar als het wat ingewikkelder wordt kun je waarschijnlijk beter met ACLs werken. Als je verschillende gebruikers hebt die samen aan sites werken worden de ACLs nog wat ingewikkelder maar dat zal ik je nu even besparen.

Voor ieder project/applicatie/site maken we een aparte PHP-gebruiker aan die leesrechten heeft op alle PHP-files (maar geen schrijfrechten, je wil niet dat een applicatie zichzelf kan veranderen). Typisch willen die PHP-processen ook ergens schrijven (bv de files die je upload via Nextcloud) en daar kun je het beste aparte directories voor gebruiken waar Apache niet bij kan, dus buiten de webroot.

We hebben dan in totaal drie gebruikers:
- apache (eentje voor het hele systeem)
- php (één gebruiker per site)
- user (één gebruiker per mens)

Als je meer wil weten kun je zoeken naar "php fpm pools".

Als ik eerlijk ben moet moet ik je wel even waarschuwen dat dit een onderwerp voor gevorderden is en als het de eerste keer is dat je met Linux werkt dan is dat wellicht wat te hoog gegrepen. Daarom zie je er ook niks over in de tutorials die op beginners zijn gericht. Ik noem het wel eens de uncanny-valley voor Tweakers. Die weten "hoe het hoort" en willen een nieuw systeem direct 100% perfect inrichten maar nemen dan teveel hooi op hun vork.

Ik denk dat je beter af bent door eerst een simplistische oplossing te proberen om een beetje ervaring op te doen met unix-users, rechten en processen, want het hele php-fpm verhaal kan een enorm doolhof worden als je die concepten niet duidelijk op je netvlies hebt staan.

[World Citizen]

@CAPSLOCK2000

Alvast enorm bedankt voor je uitgebreide antwoord. Ik zit er over te lezen en ondanks dat ik je "uncanny" helemaal begrijp ( ), moet ik het zo doen.

Ik lees even door.

[Osiris]

Overigens zijn de 'basic' (lees: non-ACL) Unix/Linux gebruikersrechten echt bijzonder simpel.

Naast de `root` user is er maar bijzonder weinig verschil tussen alle andere users, behoudens wat je met ze uitspookt.

Alle 'rechten' van die users is zo goed als verder gedefineerd in de configuratie van de diverse programma's. Zo zijn de programma's `su` en `sudo` al een paar keer aan bod gekomen. En inderdaad, dat zijn slechts *nix applicaties. En dus geen gebruikers, zoals je hier suggereert: "Je hebt standaard de Root user SUDO". `su` staat simpelweg voor "switch user" en "sudo" staat voor "super user do" (lees: "doe als superuser").

Om iets dieper in te gaan op `sudo`: dit programma wordt geconfigureerd door het bestandje `/etc/sudoers`. Daar staat in welke gebruikers of gebruikersgroepen überhaupt gebruik mogen maken van het programmaatje `sudo` en op welke manier. Zo kent de Gentoo default sudoers het volgende:

## Uncomment to allow members of group wheel to execute any command
# %wheel ALL=(ALL) ALL

## Same thing without a password
# %wheel ALL=(ALL) NOPASSWD: ALL

Met één van die twee regels kun je dus de groep "wheel" (een redelijk standaard groep binnen Linux voor 'administrator-gebruikers') heul erg breed toegang geven tot `sudo`. Voor meer info, zie: https://linux.die.net/man/5/sudoers

Verder kun je bestanden nog per user, per groep of "alles" rechten geven, waarbij groepen dus ook belangrijk kunnen zijn.

Kortom, waarbij je in Windows je in alle bochten moet wringen om de complexiteit überhaupt te kunnen begrijpen, moet je bij *nix juist lekker simpel denken

[valkenier]

Je denkt er diep over na, maar maak je het niet veel te complex? Ik heb ook een nextcloud draaien, simpelweg op standaard Ubuntu server. Apache dient als webserver, (LAMP inderdaad) en draait met www-data. Standaard Nextcloud install gedaan, nog wat beveiligingsadviezen van nextcloud opgevolgd en gaan. Op dezelfde Apache draait nog een normale website. Die zijn gescheiden in de Apache configuratie (virtual hosts). Het idee van een administrator user die processen draait zou ik laten varen. Ik ben zelf user op die server, en mag sudo. Daarmee kom je er in de wel, en gebeuren er geen rare dingen.

Verder vraag ik mij af of je idee om de nextcloud bestand ook via samba te delen je geen corrupte database van nextcloud gaat opleveren, omdat de bestanden niet via de geëigende weg (nextcloud) worden geplaatst/verwijderd. Ik heb ook wel met die gedachte gespeeld, maar dat nog om die reden nog niet geprobeerd. Mocht dat wel goed gaan dan hoor ik dat graag.

[Aherin]

Nextcloud op Ubuntu met fail2ban en SSL etc etc etc.
Waarom moeilijk doen en het wiel opnieuw uitvinden?

https://www.c-rieger.de/nextcloud-installation-guide-ubuntu/

[World Citizen]

Heren,

Ik moet dit helaas 14 dagen uitstellen. Althans, het definitief inrichten.

Mijn RAID kaart is stuk gegaan, en ik heb al een nieuwe, maar ik moet even wachten tot mijn breakout kabels binnen zijn.

Ondertussen heb ik ook een dik boek mogen ontvangen van een van mijn Linux vrienden en dat ben ik aan het doorlezen.

Als de kabels binnen zijn meld ik me hier terug en doe ik een verslag maken van alle stappen die ik heb gedaan zodat andere het eventueel kunnen nabouwen.

Alvast enorm bedankt, want door wat dingen die jullie hebben gezegd ben ik er toch anders naar gaan kijken.

[Lethalis]

Wat ik zou doen, als algemene richtlijn:
- Zorg ervoor dat deze VM in een DMZ zit.
- Probeer juist wel een package manager te gebruiken voor de installatie, want dit maakt het bijwerken van Nextcloud eenvoudiger. Nextcloud up-to-date houden is cruciaal voor de beveiliging ervan.
- Gebruik altijd HTTPS.
- Maak regelmatig backups.

[Frogmen]

@Lethalis Waarom deze VM in de DMZ lijkt mij een slecht idee want dan wordt hij niet meer beschermd door een seperate firewall en dus gevoeliger voor een hack.
Package manager maakt voor Nextcloud niet zoveel uit, vanuit de beheer console kan je de update doen.
HTTPS door Let's encrypt te gebruiken altijd een goed idee.
Backups altijd belangrijker.
@Verwijderd Besef wel dat als je iemand rechten geeft om een eigen webserver in te richten, dat je dan risico's loopt op wat deze persoon kan. Zoals eerder genoemd zal een linux goeroe het kunnen inrichten maar het is zeker niet simpel. Kan apache processen als verschillende gebruikers uitvoeren? Je kan wel een virtual host aanmaken en de map waar die naar kijkt benaderbaar maken voor een specifieke gebruiker. Lijkt mij bij vrienden en bekenden secure genoeg.
Overigens als je dit snel en simpel wilt doen, kijk eens naar ClearOS wordt er ineens heel veel werk uit handen genomen.

[Lethalis]

Frogmen schreef op donderdag 11 april 2019 @ 10:14:
@Lethalis Waarom deze VM in de DMZ lijkt mij een slecht idee want dan wordt hij niet meer beschermd door een seperate firewall en dus gevoeliger voor een hack.
Package manager maakt voor Nextcloud niet zoveel uit, vanuit de beheer console kan je de update doen.
HTTPS door Let's encrypt te gebruiken altijd een goed idee.
Backups altijd belangrijker.

Je hebt gelijk wat het DMZ betreft, dat heb ik ongelukkig geformuleerd.

Wat ik bedoel, is dat ik een vorm van netwerk isolatie zou toepassen.

Zelf heb ik bijvoorbeeld PfSense thuis met daarin aparte interfaces voor WAN (DMZ), LAN, WLAN en WEB. Dit betekent dat ik publieke services in WEB plaats. Mocht iemand ze hacken, dan kunnen ze niet verder dan het WEB netwerk en dus nooit bij mijn LAN.

Hetzelfde geldt voor wireless. Brute force je mijn WLAN dan zit je puur op mijn wireless netwerk, maar niet direct op mijn LAN

Dit heb ik overigens met VLAN's gerealiseerd en een managed switch. Maar je zou natuurlijk ook met een virtueel netwerk kunnen werken, wanneer je een VM of Docker gebruikt.

Waarom een package manager? Omdat het eenvoudiger is wanneer je een enkel kanaal hebt voor security updates en je wellicht niet altijd even veel aandacht besteedt aan een specifieke toepassing zoals Nextcloud.

Door zoveel mogelijk met apt te doen op mijn Debian systemen, weet ik vrij zeker dat alles is bijgewerkt. Ook de dingen waar ik al een tijdje niet mee bezig ben geweest.

Ik ben nogal security minded

[ Voor 5% gewijzigd door Lethalis op 13-04-2019 10:41 ]

[TheFirepit]

Lethalis schreef op vrijdag 12 april 2019 @ 21:10:
[...]

Waarom een package manager? Omdat het eenvoudiger is wanneer je een enkel kanaal hebt voor security updates en je wellicht niet altijd even veel aandacht besteedt aan een specifieke toepassing zoals Nextcloud.

Door zoveel mogelijk met apt te doen op mijn Debian systemen, weet ik vrij zeker dat alles is bijgewerkt. Ook de dingen waar ik al een tijdje niet mee bezig ben geweest.

Ik ben nogal security minded

Juist als je security minded bent is dit een vrij foute insteek. Voordat een security fix die Nextcloud doorgevoerd heeft en zelf al beschikbaar heeft via hun kanaal in de packagemanager zit ben je een tijd verder. Helemaal wanneer je met Debian te maken hebt waar alles goed getest moet zijn voordat het in de packagemanager beschikbaar komt.

De enige manier waarop het via je packagemanager zou kunnen gaan werken is wanneer Nextcloud een eigen repository heeft voor de distributie welke je gebruikt en dat je deze toegevoegd hebt aan je server.

Daarnaast had ik dan tenminste nog verwacht dat je SELinux of AppArmor aan zou halen wanneer het om security gaat (pain in the ass wanneer je er niet veel van weet, maar toch).

Frogmen schreef op donderdag 11 april 2019 @ 10:14:
@Verwijderd Besef wel dat als je iemand rechten geeft om een eigen webserver in te richten, dat je dan risico's loopt op wat deze persoon kan. Zoals eerder genoemd zal een linux goeroe het kunnen inrichten maar het is zeker niet simpel. Kan apache processen als verschillende gebruikers uitvoeren? Je kan wel een virtual host aanmaken en de map waar die naar kijkt benaderbaar maken voor een specifieke gebruiker. Lijkt mij bij vrienden en bekenden secure genoeg.
Overigens als je dit snel en simpel wilt doen, kijk eens naar ClearOS wordt er ineens heel veel werk uit handen genomen.

Afhankelijk van hoeveel je wil wat mensen kunnen zie ik geen reden waarom ze überhaupt op het systeem zouden moeten kunnen komen voor het hosten van een website. Wanneer je zelf de configuratie voor de site opzet hebben ze helemaal geen toegang tot de server nodig. Via Nextcloud zorg je ervoor dat ze hun site kunnen uploaden naar de benodigde locatie en eventueel dat ze via phpmyadmin beheer over hun database kunnen doen. Je hoeft dan alleen zelf maar de virtualhost te configureren naar de goede directory en te testen of de rechten goed staan en je bent klaar.

Wanneer je er ook nog voor zorgt dat de webserver (Apache/NGINX/...) op een non-privileged port (boven de 1024) luistert dan hoeft deze ook niks met root te doen en kan hij dus volledig onder www-data (of Administrator) draaien.

[Lethalis]

TheFirepit schreef op dinsdag 16 april 2019 @ 10:45:
[...]
Juist als je security minded bent is dit een vrij foute insteek. Voordat een security fix die Nextcloud doorgevoerd heeft en zelf al beschikbaar heeft via hun kanaal in de packagemanager zit ben je een tijd verder. Helemaal wanneer je met Debian te maken hebt waar alles goed getest moet zijn voordat het in de packagemanager beschikbaar komt.

De enige manier waarop het via je packagemanager zou kunnen gaan werken is wanneer Nextcloud een eigen repository heeft voor de distributie welke je gebruikt en dat je deze toegevoegd hebt aan je server.

Daarnaast had ik dan tenminste nog verwacht dat je SELinux of AppArmor aan zou halen wanneer het om security gaat (pain in the ass wanneer je er niet veel van weet, maar toch).

Een PPA toevoegen is misschien inderdaad het beste. De situatie die je in ieder geval wil voorkomen is dat je Nextcloud helemaal niet meer bijwerkt. Als je het handmatig installeert dan vergeet je waarschijnlijk in de toekomst om hieraan te denken en daarom zou ik het dus niet zo snel buiten een package manager om installeren.

Ik heb dat - hoe erg het ook is om dit toe te geven - vaker meegemaakt. Je installeert iets, speelt ermee, gaat daarna verder met je leven en andere speeltjes... en dan blijkt 2 jaar later dat je nog een oude versie van iets hebt laten draaien die inmiddels vulnerable is.

En dan is een Debian package gebruiken nog altijd beter

Maar goed, je zou natuurlijk ook snaps of iets dergelijks kunnen gebruiken... als je maar er aan denkt die te controleren op updates en ze ook installeert.

Waar ik wel altijd op let, is dat services met een under privileged user draaien met beperkte rechten. Dus ik zou bijvoorbeeld een nextcloud user aanmaken die alleen bij bepaalde mappen kan voor Nextcloud. Mocht Nextcloud dan gehackt worden, dan kun je alleen Nextcloud vernaggelen.

Met een AppArmor profile kun je inderdaad ook ervoor zorgen dat een proces beperkt wordt tot bepaalde rechten en bestanden. Daar heb ik eerlijk gezegd zelf tot nu toe weinig mee gedaan.

Het staat ergens op mijn lijst van 1001 dingen die ik nog in detail wil uitzoeken

[ Voor 4% gewijzigd door Lethalis op 16-04-2019 11:14 ]

[TheFirepit]

Lethalis schreef op dinsdag 16 april 2019 @ 11:10:
[...]

Een PPA toevoegen is misschien inderdaad het beste. De situatie die je in ieder geval wil voorkomen is dat je Nextcloud helemaal niet meer bijwerkt. Als je het handmatig installeert dan vergeet je waarschijnlijk in de toekomst om hieraan te denken en daarom zou ik het dus niet zo snel buiten een package manager om installeren.

Ik heb dat - hoe erg het ook is om dit toe te geven - vaker meegemaakt. Je installeert iets, speelt ermee, gaat daarna verder met je leven en andere speeltjes... en dan blijkt 2 jaar later dat je nog een oude versie van iets hebt laten draaien die inmiddels vulnerable is.

En dan is een Debian package gebruiken nog altijd beter

Maar goed, je zou natuurlijk ook snaps of iets dergelijks kunnen gebruiken... als je maar er aan denkt die te controleren op updates en ze ook installeert.

Klopt, het gebeurd heel vaak. Mensen denken dat het na het installeren wel goed is en updaten niet noodzakelijk is.

Alhoewel ik niet weet of het voor Nextcloud ook van toepassing is heb je veel producten waarbij je ook gewoon vanaf de CLI een php file aan kan roepen om te updaten. Wanneer je die scheduled zit je ook goed en dat is het in mijn ogen beter dan via de Debian repository.

Lethalis schreef op dinsdag 16 april 2019 @ 11:10:
[...]
Waar ik wel altijd op let, is dat services met een under privileged user draaien met beperkte rechten. Dus ik zou bijvoorbeeld een nextcloud user aanmaken die alleen bij bepaalde mappen kan voor Nextcloud. Mocht Nextcloud dan gehackt worden, dan kun je alleen Nextcloud vernaggelen.

Met een AppArmor profile kun je inderdaad ook ervoor zorgen dat een proces beperkt wordt tot bepaalde rechten en bestanden. Daar heb ik eerlijk gezegd zelf tot nu toe weinig mee gedaan.

Het staat ergens op mijn lijst van 1001 dingen die ik nog in detail wil uitzoeken

Voor het beperken van de rechten voor processen is SELinux of AppArmor dus weer erg handig. Met de normale access permissions op Linux kan je maar vrij weinig afschermen zonder jezelf in de problemen te brengen. Er zijn altijd zaken waarvan other tenminste read rechten moeten hebben. Om dat soort zaken af te dekken hebben ze SELinux (en de afgeleide AppArmor) ontwikkeld. Zo kan je zorgen dat het webserver proces daadwerkelijk alleen de benodigde directories met content ziet en verder geen rechten heeft.

Nadeel is dat je er wel bij het toevoegen van elke virualhost en dergelijk aan moet denken dat je alle SELinux rechten ook goed zet, want anders gaat het niet werken.

SELinux (heb niet echt ervaring met AppArmor) is erg krachtig om te gebruiken, maar het is een behoorlijke leercurve om onder de knie te krijgen. Reserveer er dus wel genoeg tijd voor wanneer je er mee bezig wil