Tag: debian

Opublikowane w

Chromium w Debianie unstable nie startuje

Gdyby komuś w Debianie unstable przestało działać chromium, a przy uruchomieniu polecenia w konsoli pokazywało się coś takiego:

$ chromium 
[4278:4278:1113/085947.509811:FATAL:zygote_host_impl_linux.cc(116)] No usable sandbox! Update your kernel or see https://chromium.googlesource.com/chromium/src/+/master/docs/linux_suid_sandbox_development.md for more information on developing with the SUID sandbox. If you want to live dangerously and need an immediate workaround, you can try using --no-sandbox.
#0 0x562ca49ba9ee <unknown>
#1 0x562ca492699c <unknown>
#2 0x562ca55b8f90 <unknown>
#3 0x562ca45f9365 <unknown>
#4 0x562ca45fe5ce <unknown>
#5 0x562ca45f7e5a <unknown>
#6 0x562ca2d09e95 ChromeMain
#7 0x7fbb5a4f6b17 __libc_start_main
#8 0x562ca2d09d3a _start

Received signal 6
#0 0x562ca49ba9ee <unknown>
#1 0x562ca49b9433 <unknown>
#2 0x562ca49ba965 <unknown>
#3 0x7fbb633dc8e0 <unknown>
#4 0x7fbb5a509f3b gsignal
#5 0x7fbb5a50b2f1 abort
#6 0x562ca49ba905 <unknown>
#7 0x562ca4926a76 <unknown>
#8 0x562ca55b8f90 <unknown>
#9 0x562ca45f9365 <unknown>
#10 0x562ca45fe5ce <unknown>
#11 0x562ca45f7e5a <unknown>
#12 0x562ca2d09e95 ChromeMain
#13 0x7fbb5a4f6b17 __libc_start_main
#14 0x562ca2d09d3a _start
r8: 0000000000000000 r9: 00007ffe7d2f0920 r10: 0000000000000008 r11: 0000000000000246
r12: 00007ffe7d2f0da0 r13: 00007ffe7d2f0f60 r14: 000000000000016b r15: 00007ffe7d2f0ba0
di: 0000000000000002 si: 00007ffe7d2f0920 bp: 00007ffe7d2f0b70 bx: 0000000000000006
dx: 0000000000000000 ax: 0000000000000000 cx: 00007fbb5a509f3b sp: 00007ffe7d2f0920
ip: 00007fbb5a509f3b efl: 0000000000000246 cgf: 002b000000000033 erf: 0000000000000000
trp: 0000000000000000 msk: 0000000000000000 cr2: 0000000000000000
[end of stack trace]
Calling _exit(1). Core file will not be generated.

to sprawa jest znana, błąd jest zgłoszony i wystarczy doinstalować pakiet chromium-sandbox.

Opublikowane w

Lynis – narzędzie do audytu bezpieczeństwa systemów Linux

Czasem zdarza się, że znajdę jakieś stare, fajne narzędzie, którego nie znałem wcześniej. Tak jest w przypadku Lynis – programu open source napisanego przez CISOfy służącego do audytu bezpieczeństwa systemu na podstawie bieżących ustawień. Przypadkiem, na komórce w tramwaju mignął mi wpis o nim gdzieś w sieci. Opis był ciekawy, więc postanowiłem dać szansę, choć od dłuższego czasu nie interesowałem się podobnymi programami. Kiedyś, na początku przygody z Linuksem bawiłem się Bastille Linux i to w zasadzie wszystko, jeśli chodzi o automaty.

Działanie Lynis sprawdzałem tylko na Debianie i Ubuntu – działa bardzo sprawnie, generuje sensowne raporty z uwzględnieniem specyfiki dystrybucji. Przy każdym raporcie jest link do krótkiego opisu z wytłumaczeniem danej opcji. Dla początkujących jest to dobra okazja do poczytania nt. ustawień i ich wpływu na bezpieczeństwo systemu. Dla zaawansowanych automat, który sprawdzi, czy czegoś nie przeoczyliśmy lub nie zapomnieliśmy włączyć np. po testach.

Program jest dostępny jako pakiet, więc instalacja sprowadza się do:

apt-get install lynis

Uruchomienie audytu również jest proste:

lynis audit system

Polecam dodanie przełącznika -Q. Program jedynie generuje raport, niczego nie zmienia w systemie, więc uruchomienie jest bezpieczne. Wynik wyświetla na ekran oraz do logu, znajdziemy tam zarówno znalezione błędy, ostrzeżenia, jak i wskazówki do hardeningu systemu.

Narzędzie ma zastosowanie raczej dla systemów, prywatnych,  utrzymywanych ręcznie. Te konfigurowane automatycznie raczej nie mają miejsca na powstanie błędu, a forma raportu jest raczej przyjazna dla ludzi, niż maszyn.

Oczywiście przy domyślnej konfiguracji zgłosi także odstępstwa od normy, które są zamierzone albo nieistotne, więc wynik będzie nieco przegadany. Mimo to polecam wypróbowanie samodzielnie.

Opublikowane w

Polecenie su – zmiany

Jakiś czas temu zauważyłem, że polecenie su w moim Debianie unstable na domowym desktopie zmieniło zachowanie. Na koncie root przestał działać skrypt do aktualizacji systemu i usypianie.

Szybko sprawdziłem i oczywiście chodziło o PATH. Dopisałem pełne ścieżki do poleceń i prawie zapomniałem o sprawie, przypuszczając, że chodzi o jakiś chwilowy błąd w którymś z pakietów.

Jednak problem nie zniknął, więc postanowiłem sprawdzić dokładnie, co się wydarzyło. Na pierwszy ogień poszło sprawdzenie /etc/profile, w którym znalazłem spodziewane:

if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"

Również w /etc/login.defs wszystko wyglądało poprawnie:

# *REQUIRED* The default PATH settings, for superuser and normal users.
#
# (they are minimal, add the rest in the shell startup files)
ENV_SUPATH PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
ENV_PATH PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Skończyły mi się pomysły, więc udałem się na kanał #debian-next z pytaniem, czy to błąd, czy może były ostatnio jakieś zmiany. I okazuje się, że zmiany były, grubsze, dotyczące polecenia su.

Uprzednio, wydanie „gołego” polecenia su zmieniało użytkownika na root oraz ustawiało należną mu ścieżkę. Obecnie należy podawać su – (forma niezalecana) lub, lepiej, su -l, aby osiągnąć ten efekt.

I jeszcze co ciekawsze fragmenty dokumentacji (man su). Było:

The current environment is passed to the new shell. The value of $PATH is reset to /bin:/usr/bin for normal users, or /sbin:/bin:/usr/sbin:/usr/bin for the
superuser. This may be changed with the ENV_PATH and ENV_SUPATH definitions in /etc/login.defs.
[...]
-, -l, --login
Provide an environment similar to what the user would expect had the user logged in directly.

Aktualnie jest:

For backward compatibility, su defaults to not change the current directory and to only set the environment variables HOME and SHELL (plus USER and LOGNAME
if the target user is not root). It is recommended to always use the --login option (instead of its shortcut -) to avoid side effects caused by mixing envi-
ronments.
[...]
-, -l, --login
Start the shell as a login shell with an environment similar to a real login:
o clears all the environment variables except TERM
o initializes the environment variables HOME, SHELL, USER, LOGNAME, and PATH
o changes to the target user's home directory
o sets argv[0] of the shell to '-' in order to make the shell a login shell

Więc gdyby komuś w jakiejś debianopodobnej dystrybucji niebawem polecenie su przestało ustawiać PATH, to najprawdopodobniej chodzi o tę zmianę.