Wat bedoel je met "user prefix"?

Als je bedoelt dat je op Linux software in je eigen home directory kan installeren en van daaruit kan uitvoeren: ja, dat kan. Ik zou het alleen voor normaal gebruik afraden. Je slaat alle voordelen van package management over en je zet allerlei software neer op een plek waar malware die onder jouw user draait (mocht dat voorkomen) er meteen kwetsbaar voor is.

De achterliggende gedachte van Linux-distributies is nou juist dat ze wél sterk package management hebben. De stabiliteit van een goed Linux-systeem wordt voor een belangrijk deel daardoor bepaald. Niet overslaan dus, maar juist gebruiken. En dan gebruik je al gauw sudo om je pakketten up-to-date te houden.

Is er een reden waarom je sudo zou willen vermijden?

Een vraag hoort wel een vraagteken achter. Jouw gebruikersdirectory is van jou(w account) en daar kun je dus dingen in neerzetten, ook programmas. Dat werkt met permissies en eigenaarschap, de naam van de directory is verder niet van belang. Of je programma dan ook makkelijk gevonden kan worden om uit te voeren is weer een ander mechanisme.

Als je van alles uitzet dan kan dat ja. Of het verstandig is? Nee, zeker niet, het is zelfs gewoon dom. Is het makkelijk te doen? Misschien wel, maar je moet wel je best er voor doen. Je kunt jezelf gewoon als alias van root aanmaken, de domste activiteit die je kunt doen. Net zoiets als als domain admin op windows gaan werken, of beter nog, met het system account. Doe jij dat ook?

Ah, wat is software, mijn shell script is ook software en doet het prima in user(space).

Het privileged identtity managment met aparte service accounts is nogal een genegeerd onderdeel in Linux land.
https://docs.splunk.com/Documentation/Splunk/8.0.3/Security/Secureyourserviceaccounts
Professionele software komt apart binnen en is bedoeld naast het OS te draaien. Aparte installatie account en run-time accounts zin nodig voor het isoleren van die software van het OS. Apart te onderhouden andere afhankelijkheden
De hardcore kale OS fanatici noemen die standaard software "applicaties" met eigen user accounts uhh ze zijn niet persoonlijk maar toegewezen aan een apart softwareprodukt. Je kunt ze beter aanduiden als services en high privileged accounts.

Het beheer kan prima met sudo ingevuld worden naar de serviceaccounts.
https://www.sudo.ws/ "Sudo (su "do") allows a system administrator to delegate authority to give certain users (or groups of users) the ability to run some (or all) commands as root or another user while providing an audit trail of the commands and their arguments."
Waarom Linux fanatici alles onder root willen draaien en geen service accounts wensen, dat is onbegrijpelijk.

Windows fanatici hebben toch juist alles onder één account draaien? Onder Linux heb je restricted accounts voor gebruikers en diverse service accounts voor specifieke services. Allerlei berichten die het tegendeel beweren zijn nepnieuws uit de bekende bron(nen).

Ten eerste zijn dit geen fanatici en de echte Windows gebruikers weten hoe het moet. Dat is bij elk OS het geval. Een goede Windows gebruiker kent een admin-account voor als het nodig is, een restricted user-account voor het normale werk. Bepaalde software wordt geïnstalleerd als een service en draait dan onder het system-account of een eigen service-account.

Maar zoals gewone thuisgebruikers van Linux een zooitje kunnen maken, doen ze dat ook bij Windows. En daar helpen bedrijven aan mee, die computers voor geïnstalleerd afleveren.

Windows kent wel degelijk service accounts en dat kunnen buiten de standaard Windows service accounts zoals System etc ook zelf gedefinieerde accounts met toegesneden bevoegdheden zijn.

Wat je met je eigen gebruikersdirectory mag hangt af van hoe de beheerder deze heeft gemount. Met de optie noexec on /home mag je geen eigen programma's executeren. Readonly gemount mag je niet wegschrijven etc etc.

Beetje vreemde vraag waarom sudo niet nodig zou zijn. Lijkt wel of ene karma dit anoniem heeft gestart om zijn offtopic nepnieuws te kunnen verspreiden. Het lijkt wel of alle windowsgebruikers (behalve Erik van Straten) niets van UNIX weten en het getroll wel leuk vinden gezien de uitblijvende reacties op ene karma4.

Een goede Linux gebruiker heeft geen admin account maar gebruikt sudo (zo iets als runas voor windows) als het nodig is. het admin account (root) is zelfs default niet geconfigureerd.
Je hebt bij windows voor het minste geringste admin rechten nodig , waardoor heel veel services met admin rechten draaien.
Mijn ervaring is dat je onder windows meer kan vernaggelen omdat er meer plekken zijn waar je de boel kan verkloten. Ik kan me nog een versie herinneren dat je het wachtwoord van een ander of zelfs de kernel als gebruiker kon weggooien. Dat is niet echt ontworpen met security in mind zou je kunnen zeggen. Nu moet ik er natuurlijk wel bij zeggen dat dat sinds NT flink is verbetert.

Ik heb niets met Windows. Het genoemde probleem met Linux fanatici met privileged account management is een van de zaken waar ik ernstige problemen mee heb. Je reactie om naar Windows te wijzen is het standaard gebeuren van het ontkennen van de eigen tekortkomingen in die wereld.

Ooit van open source en big data gehoord? Lek als een mandje. Je hoeft enkel maar naar de massale open databases open op het internet te kijken waar data van iedereen mee gelekt is.

Je hebt het over begin jaren 90. NT is gebaseerd op VMS heb ik begrepen, een beter ontwerp dan Linux en OS/2.
De ellende dat Linux niet ontworpen met een multiuser multitenancy clustering met goede security daar hebben we nu last van. Je kunt het proberen op te oplossen in plaats van naar dat andere os te wijzen
Wou je soms beweren dat de informatie via splunk en sudo links niet klopt?

Ik neem aan dat je Splunk aanhaalt als voorbeeld van professionele software. Voor installatie op Linux raden ze aan de "splunk"-user te gebruiken die automatisch wordt aangemaakt als je het via de package manager installeert, en anders een eigen user met beperkte rechten. Klopt helemaal met wat je zegt.

Maar dan wat ze voor installatie op Windows aanraden:
Ik ben geen Windows-kenner, dus moest ik even opzoeken wat die local system context precies inhoudt, en kwam omschrijvingen als deze tegen:
Oeps, dat is toch precies wat je vooral niet wilt? Maar een account met beperkte rechten raden ze enkel aan als een Windows-communicatiekanaal wordt gebruikt, en anders noemen ze een generieke user met erg veel rechten als "vaak de beste keuze".

Als iemand die altijd het belang van service accounts benadrukt, kan jij uitleggen waarom deze professionele software daar op Windows zo nonchalant mee omgaat?

Zou je je vraag iets duidelijker willen omschrijven, dan krijgen we geen non discussie met karma4 in de thread.

Het zou best karma4 als anoniem kunnen zijn (doet hij wel vaker) gezien het slechte taalgebruik, zodat hij weer offtopic los kan gaan met zijn nepnieuws.

Grappig, daar zat ik ook al aan te denken.

Maar ik ben het gezeik met hem wel kots beu en de @redactie doet er helemaal niks aan. Zou Karma4 ook de mod zijn alhier?

Ik ben die anoniem niet. Wel is een vraag uit de praktijk te herkennen. Gebruikers worden niet goed geholpen, niet uitgelegd wat de keuzes zijn bij hun vraag. Uiteindelijk zie je ze in shadow ict (het zelf doen) vluchten.

Je hebt gelijk ook op Windows zie je de externe leveranciers de gemakkelijke weg kiezen. Nu valt de schade daar nog mee omdat de meeste servers op Linux draaien. Ik vind die houding via externe leveranciers niet kunnen.
De enkele keer dat ik met Windows servers me te maken had waren de server beheerders bereidwillig om geen local system account te gebruiken. Ze noemen bij Splunk tenminste nog dat je een keus hebt en beter voor dat restricted account kunt gaan (apart service acccount).

Heb je door dat je met Splunk onder dat RPM onder root wordt geacht te werken. Nu hebben ze al een stap gemaakt voor een apart account, Gelukkig ook daar " or create your own user that only has privilege and ownership over $SPLUNK_HOME." Er is geen verschil tussen beide OS-sen.
De vraag met Liniux: Welke id en gid moet daarvoor via LDAP neerzetten? de constructie is niet zo voor de hand liggend dat je met het scriptje draaien er vanaf bent. Daar zit nu net de problematiek van het beheer rond privileged access.

Ik moest wel goed zoeken om een goed voorbeeld te vinden. Splunk is het tool voor een SOC waar de veiligheid voorop zou moeten staan. Het valt me allemaal nogal tegen.

Omdat je er geen kaas van gegeten hebt, geen training hebt gevolgd en alles van internet plukt.
SMT geeft in Nederland prima trainingen voor Splunk, dan kan je meteen zien hoe het wel moet.

Splunk geeft prima trainingen over hoe zij vinden dat hun product neergezet moet worden. Doen IBM Oracle SAP etc ook.

Waar het mis gaat is het privileged identity management (en de rest) binnen een organisatie.
Heb je ergens gevonden of een link bij een externe dienstverlener hoe de informatiebeveiliging als geheel ingericht moet worden bijvoorbeeld bij een bank? Of beweerde je nu net dat de installatiecursus van Splunk daarvoor volstaat. Dit kan ik van internet pukken: https://www.smtware.com/knowledge-base/information-security-zekerheid-als-einddoel/

Rare claim die je hier maakt. Onder *nix is het standaard dat daemons (aka 'services') onder een eigen user/group-naam draaien.

Dat klinkt een stuk milder dan wanneer je kritiek hebt op het niet gebruiken van service accounts op Linux, dan kan je ronduit giftig overkomen en is er meteen iets fout met de mentaliteit van iedereen die er iets mee te maken heeft, zo lijkt het dan wel. Vanwaar dat verschil?

Nee, er staat expliciet dat als je RPM gebruikt er een account dat "splunk" heet wordt aangemaakt. Pas als je buiten package managmentsoftware om gaat installeren moet je zelf iets regelen. En dan raadt men niet aan om maar onder root te draaien maar om een account als dat "splunk"-account aan te maken.

Bij Linux is het automatisme dus een service-account, en als je het automatisme niet gebruikt is een service-account het advies. Bij Windows is er om te beginnen helemaal niet zo'n automatisme, afgaande op die pagina, en raden ze het aanmaken van een service-account pas aan onder bepaalde condities.
Dat verschil is er duidelijk wel.


Er zijn hele reeksen services aan te wijzen die in Linux-distro's, net als Splunk hier, een service-account aangemaakt krijgen als onderdeel van de installatie. User www-data voor apache, user lp voor cups, user avahi voor avahi, user clamav voor de clamav update daemon, ga zo maar door. Is er iets mis met voorbeelden die standaard in Linux-distro's zitten?

ja maar dat is precies wat karma noemt vaak een "genegeerd onderdeel"...

Proest!!! Je maakt met dit soort opmerkingen niet bepaald de indruk ooit in een complexe professionele omgeving gewerkt te hebben, zoals een bank. Natuurlijk beschrijft de installatiehandleiding van welk pakket dan ook niet hoe de informatiebeveiliging van een hele bank moet worden ingericht. Dat zijn complexe organisaties met complexe IT waar het gierend in het honderd loopt als ze zelf de kennis en kunde niet in huis hebben om maatwerk voor hun eigen situatie te maken. Daar haalt men de kennis over hoe ze informatiebeveiliging voor de hele organisatie moeten doen echt niet uit de installatiedocumenten van een softwareleverancier. Het idee is lachwekkend.

Waarom dacht je dat ik die vraag stelde. Het is inderdaad belachelijk dat een enkele externe leverancier waarvan er velen zijn zou gaan voorschrijven hoe de informatiebeveiliging bij een organisatie ingericht moet worden.
Dat is waar je in de praktijk wel tegen aan loopt.

De vraag welke high privileged acties door welk account wanneer onder welke condities uitgevoerd mag worden is er een die je met sudo kan oplossen. Veel te lastig verhaal voor Linux evangelisten als je daar mee aan komt. Voor je het weet krijg je het antwooord om maar naar een Windows server aanpak over te stappen omdat zij het onder linux niet aan kunnen.
De link naar dat SMT blog, daarin zie je dat zelfde terugkomen. Het is een goede dienstverlener en een net blog.
"Maar de IT-afdeling had een eigen platform, net als de financiële afdeling. Het waren allemaal eilandjes. Wij hebben ons ingezet om alles samen te brengen "


Als je voor zo'n vraag als sudo beheer, meerdere gescheiden privileged accounts ontvangen wordt bij de Linux mensen da ze zoiets niet doen, hun OS veilig is en dat de applicatie het zelf maar moet uitzoeken dan wordt het lastig normaal te communiceren. Nog kwalijker is dat dat soort vragen voor samenwerking afgedaan door worden Linux evangelisten om naar een os flaming over te stappen. Vind je het dan vreemd om reacties terug te geven.
Het vriendelijk blijven vragen werkt niet, dus maar wat anders.

Op dat deel hebben we enkel nog maar over de installatie (in rest) we moeten nog naar data in transitie.

Nou minder dan je zo stellig beweert, Ik moest even kijken wat dat WMI nu inhoud. Dat is al het geval als het onderdeel is van een domain (AD meerdere servers). Dan is er nog het onderscheid "ïn-rest" en "in-transitie"
Het "in-rest" deel is wat in llinux naar /opt gaat en onder Windows naar "programfiles"
De"in-transitie"is wat in Linux voor een deel zichtbaar is met "ps -ef" en wat je met Windows onder Services (local system) terugziet. Natuurlijk veel technische details welke verschillen.

Wat gelijk blijft zijn de vragen:
- Wie mag wanneer deze aangekochte software bijwerken en hoe gaat dat met de validaties naar de organisatie
- Als deze aangekochte software draait hoe stel je vast wie waar bij mag en hoe zit dat met shared accounts personal accounts en service accounts met de betrokken achterliggende informatie.

[/quote] Er zijn hele reeksen services aan te wijzen die in Linux-distro's, net als Splunk hier, een service-account aangemaakt krijgen als onderdeel van de installatie. User www-data voor apache, user lp voor cups, user avahi voor avahi, user clamav voor de clamav update daemon, ga zo maar door.
Is er iets mis met voorbeelden die standaard in Linux-distro's zitten?[/quote]Zie hierboven, wat ontbreekt is de complete afstemming naar informatiebeveiliging.
Een standaard installatie setup-enter-enter is dat je het werkend ziet. Daarna begint het pas om het echt veilig te krijgen met de informatie van de organisatie. Neem Splunk, die moet daarna overal bij logs zijn data halen met zeer beperkte rechten (andere service accounts). Als je daarvoor root of database dba rechten gaat gebruiken dan is dat niet best. Het werkt wel met zoveel rechten, er werkt veel te veel wel.

Neen Karma4 Splunk gaat geen logs halen met root rechten, daarvoor heb je splunk-forwarders die met beperkte rechten draaien.

Dat is inderdaad wel duidelijk.


Executables buiten user context neerzetten is inderdaad juist een voordeel. Als je een scheiding hebt tussen gebruikersgegevens en besturingssysteemgegevens dan kunnen die laatste niet worden gecorrumpeerd door malware die een gebruiker oploopt/uitvoert. Een gebruiker kan dan nooit het systeem zelf kapotmaken. Dat maakt herstel veel gemakkelijker. Een van de voordelen van Linux is dat een restricted account / beperkt account standaard wordt ingesteld.

Dan heb je het over serviceaccounts met beperkte rechten. Die moet je netjes beheren en inregelen.
Wil je die service accounts niet dan heb je of een ondoorgrondelijk iets dan wel root rechten.
https://docs.splunk.com/Documentation/Forwarder/8.0.3/Forwarder/Installanixuniversalforwarder Ik zie geen accounts rechten voor de installatie nog voor de executie. Alleen een install enter-enter-enter verhaal.
Onderin staat een verwijzing wat je moet doen als je het als non-root wil draaien. Let op met poort 514.
https://docs.splunk.com/Documentation/Splunk/8.0.4/Installation/RunSplunkasadifferentornon-rootuser

Splunk wordt door nogal wat knoppendrukkers in de security gezien. Nu moet je het eens als standaard patroon voor andere software "applicaties" op een gedegen manier doen. 600+ keer herhalen. Dan hebben het niet eens over de rechten van naar de gevoelige bedrijfs/organisatie zaken. SMT blog gelezen? silo's en wanorde is gangbaar, wat is daarvan de oorzaak ….

Al lang weerlegd en tevens een reactie op de verkeerde die reageerde. Daarmee onderbouw je het probleem van het onaangepaste gedrag waarnaar een andere reageerder naar vroeg. Mijn dank er voor dat de professionele insteek in Linux evangelisme ontbreekt waar informatiebeveiliging het doel zou moeten zijn.

Een service account goed inregelen met gedelegeerd beheer is nu net iets waar je fel op tegen bent want dat is voor de applicatie niet voor de os-evangelist. Dat zo'n vraag gesteld wordt toont de achterliggende problematiek van het zelf maar moeten uitzoeken..

Het lijkt met dat evangelisme erg mee te vallen als Linux-evangelisten zo makkelijk voor een "Windows server aanpak" kiezen. Verder zou je misschien eens met deskundigen moeten gaan praten in plaats van met evangelisten, dan ontstaat er vermoedelijk een heel ander beeld.
Alleen werkt wat je dan maar doet evenmin, en ik denk nog veel slechter. Want je bent zelf vaak stevig aan het flamen en daar reageren anderen weer zwart/wit op. Het werkt polariserend. Je bestrijdt die polarisering niet door er een schepje bovenop te doen, je bestrijdt het door het juist niet te doen. Moeilijk, ik weet het, ik laat me ook verleiden om op jou te reageren nu.
Pardon? Dat zijn niet accounts die gebruikt worden om de installatie te doen, dat zijn accounts waaronder de service gaat draaien, "in transitie" dus volgens de nogal vreemde definitie die jij daarvan geeft.
Opmerkelijk dat iemand die kennelijk kan beoordelen wat een "Windows server aanpak" is niet van ingebouwde beheerhulpmiddelen op de hoogte is.
Dus "in-rest" is de geïnstalleerde software zoals die op de schijf staat en "in-transitie" is de software zoals die als taak actief is in het geheugen van een computer. Dat is een heel andere onderscheid dan tussen data at rest die op een specifiek apparaat staan en data in transit die bezig zijn van een apparaat naar een ander getransporteerd te worden. Heb je maar besloten er wat termen die met informatiebeveiliging te maken hebben tegenaan te gooien in de hoop dat je geleerd overkomt?

De opmerking aangaande windows lijkt me niet waar, zeker binnen bedrijven is het het uitermate onwaarschijnlijk dat je op de omgeving werkt een account hebt met local admin, dat zou ernstig indruisen tegen alle security adviezen. Wat je thuis doet moet je maar zelf weten, alhoewel het ook dan niet verstandig is om onder local admin te draaien, dit heeft voor malware namelijk het voordeel dat deze geen rechten escalatie hoeft te doen wat dan voor de eigenaar van de PC weer een nadeel is ;-)
Tevens kun je bij Unix/Linux veel minder granualair werken met rechten (rwx voor uid 0/group/user) terwijl dit binnen het Windows OS mijn inziens beter in te regelen is, maar dat is mijn mening ......

Als jij thuis een distro installeert met default settings heb je een werkende omgeving met het UNIX permissie systeem wat jij noemt. Dat wil niet zeggen dat er dan geen andere (meer detail) mogelijkheden zijn. Ga er maar van uit dat een Linux systeem veel flexibeler is dan je denkt. Je kan je desktop ook joinen in een windows domein en (bv gnome) policy settings opgedrongen krijgen. De ubuntu bash onder windows10 werkt met POSIX ACLs om bij het windows permissie model te kunnen aansluiten.
Het filesysteem moet dan natuurlijk wel Access Control Lists op files en directories supporten. Doe maar eens in de shell: $man acl
Misschien heb je ook wel eens gehoord van Samba of CIFS? https://www.kernel.org/doc/html/latest/admin-guide/cifs/usage.html?highlight=ntfs

Je reageert normaal, prima. Als normale communicatie niet werkt dan is de enige keus polarisering. Het vraagt in ieder geval aandacht en werpt zo een blokkade op. Ik denk niet dat het slechter is, het is het diepe dal om tot verbetering te kunnen komen. Zonder erkenning van de problemen blijft het modderen.

Nee bewuste keuze ik zag dat het installeren van de software (splunk account) en het draaien van en proces (local system service) door elkaar gehaald werden. De enige aanduiding die het overeenkomstige onderscheid is met "ïn-rest" en "in-transitie". Het gaat dan wel over data informatie in het algemeen/ Software is ook data opslag op een specifiek apparaat. Als die software gegevens verwerkt dan krijg je een andere invalshoek voor de beveiliging. Waar komt dat vandaan gaat het heen welke encryptie, wie-account en logging.
Ik wist geen betere aanduiding, heb jij die?


Het is een aanduiding van Splunk zelf, ik heb vaak gezegd dat ik niets met Windows heb, wel met informatieveiligheid. Bi big data met de achtergrond van de technische systemen tot het laagste niveau. je ziet dan van alles hoe met gevoelige data om gegaan wordt. Op tijd de ogen dicht doen dan wel lijden aan beroepsblindheid..

Dat zie ik totaal anders: vooral de flut-buntu gebruikers kun je onder die noemer weg zetten. Alle overige enteprise beheerders en senior gebruikers weten hier wel degelijk goed mee om te gaan,die gebruiken zelfs SELinux of Apparmor.

hoe het even zuiver please:

https://help.ubuntu.com/community/AppArmor

staat std aan en enforcing op zo een flut-buntu. als gebruiker heb je er vrijwel geen omkijken naar aan.

Ik ben maar een simpele user. Maar toen ik in de jaren negentig informatica studeerde, moest ik mijn zelfgeschreven programma's in mijn eigen user directory compileren en uitvoeren. Om de simpele reden dat ik geen admin rechten op Solaris had.

Ook als je een andere browser wilde als Mosaic, bijvoorbeeld Netscape, dan moest je die in de eigen user directory neerplanten.

Ik geloof dat we iets van 10 MB hadden per user, maar als je meer nodig had kon je dat vragen aan de helpdesk en kreeg je dat ook.

Eindhoven?

Precies, software kan prima in een eigen user directory zeker als je systeem een single-user systeem is.

Het kan, maar of het verstandig is, is een tweede.

Zelfgeschreven software die toch maar door één gebruiker gebruikt wordt doet het prima in $HOME/bin, maar bijvoorbeeld een andere browser doet het beter als systeem-brede installatie want dat scheelt opslag, backup-ruimte, en zo verder. Daarnaast heb je het probleem dat als er shared libraries in het spel zijn, upgrades die zelf-geinstalleerde programmas kapot kunnen maken en dan moet je dat dus dan zelf weer oplossen.

En soms is het ook wel handig om ook je eigen software via het gebruikelijke package-systeem te installeren. Dus zelf package maken en dat op je machientje installeren. Sommige packaging-systemen lenen zich daar erg goed voor, andere minder.

Oftewel, zeker op gedeelde systemen is het meestal verstandiger en wel zo netjes om de beheerder vriendelijk om je extra software te vragen.

een goede werkende ballans is als het in de centrale repo van je OS zit, installeer het OS breed met je package manager want dan krijg je ook updates. zit het niet in de repo, dan kan gebruiker zelf aan de slag in ${HOME} en voor veel (wetenschappelijke) software kun je dan ook nog eens verwijzen naar EasyBuild.

Nu nog zelf even een goede balans met aanhalen en een nuttig punt toevoegen vinden.

Hoeft niet, met flatpak https://www.flatpak.org/ kan je applicaties (en runtime omgeving) isoleren van de host en toch updaten met "flatpak update" Dat gebruik ik voor spotify https://flathub.org/home[/quote]Flatpak is niet de enige er zijn er meer. Zo is er ook snapd voor itunes b.v. Zo gebruik ik ook nog een torbrowser geinstalleerd in mijn $HOME. Die update zich zelf, zoals al die applicaties onder windows ook doen omdat ze niet worden gesupport door windows update. Hence de neem windows.Blijft dat je keuze hebt om het systeembreed te doen of niet.