Dotaz: Zákaz procházení adresářové struktury pro uživatele

[pajito]

Dobrý den, rád bych na serveru, kam mají přístup uživatelé uvedení v LDAPu, zakázal procházení adresářové struktury v ubuntu 12.04. Aby nemohli otevřít případně změnit soubory v /etc či jiných adresářích, kromě těch, kam jim to povolím, např. home složka. Můžete mi poradit jak toho docílit?

Děkuji za každou radu

---

---

Odpovědi

[Jendа]

Změnit snad nemůžou už teď.

setfacl -Rm user:jenda:--- /etc; setfacl -Rm default:user:jenda:--- /etc

[r]

Otazka na telo: pres jakou sluzbu? Prochazeji adresarovou strukturu na disku pres ssh, ftp, cifs, ...? Podle sluzby proved chroot uzivatelu.

[pajito]

mohou se přihlásit pomocí sftp, ftp a ssh

[r]

Cekal jsem trosku jinou odpoved, ale co uz.
Tak google a zadam vsftpd (pokud mam vsftpd, proftpd, ...) chroot user, atd. Pro ssh chroot ssh user, atd.

[Max]

ftp servery umí chroot sami o sobě. Pokud jde o ssh/sftp, tak bych použil jailkit
Zdar Max

[Sten]

SFTP a FTP jde chrootovat. SSH sice teoreticky také, ale uživatelé pak nemohou spouštět binárky mimo ten adresář. A pokud povolíte /usr/bin, tak ty binárky často potřebují i přístup do /etc, aby fungovaly nějak rozumně.

Pro SSH přístupy bývá IMO vhodnější vytvořit virtuál, kde v /etc není nic citlivého.

[Max]

Pro ssh chroot se právě používá jailkit, který vytvoří chroot se všemi app, které máš v jeho nastavení nadefinované.
Vytvoří ti tedy v domovském adresáři "etc, var, usr, lib" apod. + v návaznosti na seznam app, které chceš mít součástí chrootu, zjistí závisloti na konkrétních knihovnách a ty také nakopíruje. Uživatel má tedy klasickou adresářovou strukturu, jen s tím rozdílem, že tam má tebou definované app + nezbytné knihovny a celé to je zastřešeno aclkem, aby nemohl nic upravovat apod. V /etc/passwd apod. je jen jeho uživatel, nic jiného atd.
Je to bezpečné a nenáročné řešení. Virtual peer user je úplně zbytečný overkill.
Zdar Max

[MP]

A upgraduje je taktez?

[Max]

jk_update
Zdar Max

[Filip Jirsák]

K tomuhle slouží na souborovém systému oprávnění. K tomu, co popisujete, stačí klasická unixová oprávnění – každý soubor má přiřazeného uživatele (vlastníka) a skupinu, a má určená oprávnění pro vlastníka, skupinu a pro ostatní. Pokud je uživatel shodný s vlastníkem souboru, uplatní se na něj oprávnění pro vlastníka, pokud je členem skupiny, které patří soubor, uplatní se na něj práva skupiny, v ostatních případech se na něj uplatní práva pro ostatní. Pozor, vyhodnocuje se to v tomhle pořadí a první vyhrává, tj. pokud je uživatel vlastník souboru a zároveň je členem skupiny souboru, uplatní se jen práva vlastníka a pro daného uživatele je úplně jedno, jaká jsou nastavena práva pro skupinu. Práva jsou tři, r (read), w (write) a x (eXecute). Na souborech znamená právo r právo číst obsah souboru, právo w právo soubor editovat, a právo x právo soubor spustit (jako spustitelnou binárku – nevztahuje se to na skripty, tam spouštíte binárku interpretu a ta pouze čte soubor se skriptem). Na adresáři znamená právo r právo vypsat seznam souborů v adresáři, právo w znamená možnost vytvářet, přejmenovávat a mazat soubory v adresáři, právo x znamená právo vstoupit do adresáře (udělat do něj cd) – bez toho práva se nedostanete ani do podadresářů (když uděláte cd /a/b/c a nemáte právo x na /a, dovnitř se nedostanete, interně se to provádí jako tři postupné skoky vždy o jeden adresář.) Pozor na to, že i běžný uživatel potřebuje oprávnění číst na spoustu souborů v /etc, na druhou stranu v běžných distribucích jsou výchozí práva nastavena rozumně, takže běžný uživatel nebude mít práva zapisovat třeba nikam do /etc.

Omezovat přístup až na úrovni konkrétních programů, jak tady píšou ostatní, je spíš taková obezlička, vždycky v tom programu může být nějaká chyba nebo si neuvědomíte nějakou interakci a uživatel vám z toho omezení uteče. To, co jsem popsal já, jsou oprávnění přímo na úrovni operačního systému, ty žádný program neobejde, i kdyby se na hlavu stavěl.

[Josef Kufner]

… leda by zneužil díru v jádře (viz rootování Android telefonů).

Jinak pokud jde o to, aby uživatel neviděl obsah adresáře, lze tam ponechat x, ale odebrat r, takže pokud zná název souboru, může k němu, ale nezjistí, jaké další soubory tam jsou. Běžně se to nastavuje u různých adresářů ve /var/spool.

Pak je tam ještě pár dalších věcí, konkrétně sticky bit, SUID a SGID bity – unix oprávnění josu čtyři číslice v osmičkové soustavě. O komentář výše jsou popsané poslední tři.

Doporučuji si přečíst nějaké povídání o tomto, nejspíš zjistíš, že to opravdu stačí.

[lertimir]

a právo x právo soubor spustit (jako spustitelnou binárku – nevztahuje se to na skripty, tam spouštíte binárku interpretu a ta pouze čte soubor se skriptem).

No ale to myslíš snad jen skripty, které spouštíš např. perl skript.pl, ale když máš skript script na jehož začátku mám #!/usr/bin/perl a potom pokračuje kód v perlu, tak mu musíš přiřadit x jinak ti shell oznámí, že ho nespustí. (a tomuto říkáme také skript). Tedy alespoň u mne. To co napsal mne překvapilo a tak jsem zkusil skriptům odebrat x.

[Josef Kufner]

To zmotal s SUID bitem. Právno na spuštění potřebuješ jak u interpretu, tak u skriptu.

[alkoholik]

Kecas.

~$ cat kecas.sh 
#!/bin/sh
echo Kecas
~$ ls -l kecas.sh 
-rw-rw-r-- 1 user user 21 led 28 13:01 kecas.sh
~$ bash kecas.sh 
Kecas

[Josef Kufner]

Na to abys ten skript spustil. Tedy abys mohl udělat:

./kecas.sh

To, že ručně spustíš interpret je o něčem jiném. Navíc v tomto případě spouštíš jiný interpret, než jaký je uveden ve skriptu.

[Filip Jirsák]

Z pohledu oprávnění je to tak, že odebráním práva x skriptu nezabráníte jeho spuštění. Interpretaci #! na začátku skriptu dělá shell, takže si klidně můžete napsat shell, který vám ./script.pl spustí, i když nebude mít právo x. Na druhou stranu když máte nějaký binární program bez práva x, ale s právem r, taky vám nic nebrání udělat si jeho kopii a té právo x nastavit a program spustit. Takže ve výsledku je to vlastně stejné.

[Josef Kufner]

Interpretaci #! na začátku skriptu dělá shell, [...]

Ne. Tu interpretaci dělá jádro.

[Filip Jirsák]

Aha. Obecně na unixových systémech to dělá shell, ale někde to je zjevně zadrátované i do jádra.

[pako]

No já nevím. Podíval jsem se na další UNIXový systém (Solaris) a dělá to úplně stejně jako Linux. Rodič (shell kde to pouštím) udělá fork() a pak nový proces zalidní execve("./test.csh"...). Do teď jsem byl přesvědčen, že systémová volání nejsou zpracovávána shellem. Takže si nejsem jistý ani správností ani obecností tvrzení, že to dělá shell.

[Josef Kufner]

Kdyby to dělal shell, tak by to naprosto postrádalo pointu celé té věci. Jsem si celkem jistý, že to bude záležitostí jádra všude, co jen trochu smrdí unixem, tedy vyjma Windows, kde to je podle přípony.

[Filip Jirsák]

man bash

COMMAND EXECUTION

If the command name contains no slashes, the shell attempts to locate it. […]

If the name is neither a shell function nor a builtin, and contains no slashes, bash searches each element of the PATH for a directory containing an executable file by that name. […]

If the search is successful, or if the command name contains one or more slashes, the shell executes the named program in a separate execution environment. Argument 0 is set to the name given, and the remaining arguments to the command are set to the arguments given, if any.

If this execution fails because the file is not in executable format, and the file is not a directory, it is assumed to be a shell script, a file containing shell commands. A subshell is spawned to execute it. This subshell reinitializes itself, so that the effect is as if a new shell had been invoked to handle the script, with the exception that the locations of commands remembered by the parent (see hash below under SHELL BUILTIN COMMANDS) are retained by the child.

If the program is a file beginning with #!, the remainder of the first line specifies an interpreter for the program. The shell executes the specified interpreter on operating systems that do not handle this executable format themselves. The arguments to the interpreter consist of a single optional argument following the interpreter name on the first line of the program, followed by the name of the program, followed by the command arguments, if any.

man zshmisc

COMMAND EXECUTION If a command name contains no slashes, the shell attempts to locate it. […]

Otherwise, the shell searches each element of $path for a directory containing an executable file by that name. If the search is unsuccessful, the shell prints an error message and returns a nonzero exit status.

If execution fails because the file is not in executable format, and the file is not a directory, it is assumed to be a shell script. /bin/sh is spawned to execute it. If the program is a file beginning with `#!', the remainder of the first line specifies an interpreter for the program. The shell will execute the specified interpreter on operating systems that do not handle this executable format in the kernel.

(Až k té části „pokud to nedělá kernel“ jsem poprvé nedočetl, proto jsem byl přesvědčen, že to dělá jenom shell.)

[Max]

Nesouhlasím. Chroot/jail je dobrý, že chci třeba zamaskovat obsah "/etc/passwd" a "/etc/group", s jailem to udělám, bez něj nikoli.
A proč maskovat tyto soubory? Mno, třeba nechci,aby uživatel viděl, kdo všechno má na server přístup.
Těch důvodů, proč dělat chroot/jail je více. A navíc, to že někdo dělá chroot / jail neznamená, že musí mít nutně bordel v oprávnění v systému. Člověk by měl mít jednak pořádek v oprávněních + třeba u hostingu je vhodné mít další vrstvu navíc a mít uživatele v jailu.
Resp. pořešený oprávnění v rámci systému + jail + acl + třeba i selinux.
Já prostě nevidím důvod, proč nemít více ochranných vrstev.
Zdar Max

[Filip Jirsák]

Více ochranných vrstev klidně může být. Ale nikdo tu nenapsal, že se takováhle věc řeší především nastavením souborových oprávnění, a teprve pak případně můžu přidávat další vrstvy. Navíc chroot funguje jen pro vzdálený přístup, chroot pro lokální přístup by asi znamenalo dost ohackovat login a bůhví, jak by to pak fungovalo.