Forum Debian Users Gang

Jakis tam sterowniki nowe i stare  są w portach
https://www.freshports.org/search.php?query=nvidia& … seinsensitive




Co do desktopu na FBSD jest sobie taki wątek na forum freebsd
https://forums.freebsd.org/threads/why-freebsd-over … esktop.62028/

bryn1u napisał(-a):

Czego sie spodziewac po zwyklym systemie desktopowym, ktory nie jest przeznaczony na servery. Proponuje to zrobic z OpenBSD, a jeszcze lepiej z HardenedBSD

A czy ja pisałem o OpenBSD? Po prostu gościu zrobił sobie forka FreeBSD i go przy tym spartaczył a sam pokaz połamania tego dziadostwa może też służyć jako przestroga dla tych, którzy zechcą używać jakiś egzotycznych mało popularnych forków dobrych systemów jakim jest niewątpliwie FreeBSD.

bryn1u napisał(-a):

Nawet bys tego nie odpalil.

To do odpalenia OpenBSD trzeba być inżynierem kwantowym na wydziale kondensatu fermionów?

bryn1u napisał(-a):

W ubuntu jest jakas tam ochrona apparmor / acl

Tak szkoda, że nie wspomniałeś, że praktycznie wszystkie profile apparmora są domyślnie powyłączane lub nieskonfigurowane nawet te najważniejsze jeżeli chodzi o desktopa czyli do domyślnej przeglądarki www. Po za tym co za problem doinstalować sobie apparmora na debku:

root@debian:~# systemctl status apparmor.service
● apparmor.service - AppArmor initialization
   Loaded: loaded (/lib/systemd/system/apparmor.service; enabled; vendor preset: enabled)
   Active: active (exited) since Fri 2018-07-13 10:06:50 CEST; 13h ago
     Docs: man:apparmor(7)
           http://wiki.apparmor.net/
  Process: 613 ExecStart=/etc/init.d/apparmor start (code=exited, status=0/SUCCESS)
 Main PID: 613 (code=exited, status=0/SUCCESS)

lip 13 10:06:50 debian apparmor[613]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.dnsmasq
lip 13 10:06:50 debian apparmor[613]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.dovecot
lip 13 10:06:50 debian apparmor[613]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.identd
lip 13 10:06:50 debian apparmor[613]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.mdnsd
lip 13 10:06:50 debian apparmor[613]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.nmbd
lip 13 10:06:50 debian apparmor[613]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.nscd
lip 13 10:06:50 debian apparmor[613]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.smbd
lip 13 10:06:50 debian apparmor[613]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.smbldap-useradd
lip 13 10:06:50 debian apparmor[613]: .
lip 13 10:06:50 debian systemd[1]: Started AppArmor initialization.

i dodatkowo firejaila:

user@debian:~$ firejail --list
842:user::firejail /usr/bin/chromium --start-maximized 
23076:user::firejail deadbeef

a jak ktoś ma syndrom oblężonej twierdzy to może jeszcze dorzucić łatkę grsecurity+PaX-a, nie widzę problemu. Jest nawet gotowe jajko w repo:
https://packages.debian.org/search?keywords=linux-i … 4-grsec-amd64

Poruszyłeś zupełnie inny temat i nie wiem skąd to oburzenie, przecież nigdzie nie napisałem, że Debian jest jakimś 'kuloodpornym' systemem.

Ostatnio edytowany przez hi (2018-07-14 01:04:36)

Jacekalex napisał(-a):

Yampres napisał(-a):

W ubuntu jest jakas tam ochrona apparmor / acl. W systemach redhatowych selinux, gdzie dobrze chroni, a zwlaszcza jak user jest zmapwany do user_u i pracuje w swojej domenie. Podsumowujac, debian nie ma defaultowo niczego co by go chronilo przed exploitami lub shellcode

Debian ma tego samego AA, włącznie z bibloteką apparmor-pam, tylko po prostu trzeba to włączyć i skonfigurować, jak wszystko.

SELinuxa też możesz w każdym Linuxie włączyć, chociaż im dalej od RH,
tym bardziej nieprzewidywalny jest SELinux i tym więcej z nim potencjalnych problemów.


W klasycznym hardeningu Debian też nie śpi:

Kod:

# Debian ###   sob lip 14 01:26:44  domek : / 
root ~> hardening-check `which mplayer`
/usr/bin/mplayer:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: yes (some protected functions found)
 Read-only relocations: yes
 Immediate binding: no, not found!

Także może Debian nie jest liderem peletonu, ale utrzymuje rozsądny dystans przed realnymi zagrożeniami.

Kod:

# Debian ###   sob lip 14 01:34:48  domek : / 
root ~> hardening-check `which pidgin`
/usr/bin/pidgin:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: yes (some protected functions found)
 Read-only relocations: yes
 Immediate binding: yes

W Gentoo:

Kod:

hardening-check `which pidgin`
/usr/bin/pidgin:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: yes
 Read-only relocations: yes
 Immediate binding: yes

Jest coraz mniejsza różnica miedzy Debianem a moim Gentoo hardnened pod względem hardeningu kompilatorów.

Co ciekawe, to nawet nie zawsze robota Developerow Debiana, po prostu GCC pod tym względem idzie stale do przodu, bez hałasu i krzyku, ale skutecznie.

Pozdro
;-)

Te wszystkie flagi, ktore wymieniles to jest "sredniowiecze". To sa podstawy podstaw. Pytanie jeszcze, jaki jest tam fstack-protector ? fstack-protector czy fstack-protector-strong czy fsctack-protector-all (fsctack-protector-all  jest much powerfull.). Wydaje mi sie, ze ten pierwszy, ale nie daje sobie reki obciac. W HardendBSD paczki oprocz tych wszystkich flag i fstack-protector-all sa skompilowane dodatkowo z  SafeStack czyli oddzielenie stosu bezpiecznego od niebezpiecznego -> https://clang.llvm.org/docs/SafeStack.html.
Nastepnie od wersji HBSD-12 (juz niedlugo) paczki dodatkowo beda zbudowane z CFI czyli Control Flow Integrity -> https://clang.llvm.org/docs/ControlFlowIntegrity.html. I to dopiero zwieksza znacznie bezpieczenstwo przed buffor overflow. Gentus tego nie mial i nie bedzie mial dopoki uzywa GCC bo w GCC nie jest to zaimplementowane. W 2016 na liscie mailingowej GCC, poszla prosba o zaimpilementwoanie SafeStack do gcc, ale zostalo to bez odpowiedzi i nikt nie wykazal zainteresowania w celu podniesienia bezpieczenstwa czyli jak na linuxa przystalo.

Nie wiem czy widziales, ale jest projekt, ktory stworzyl i rozwija polak -> http://www.openwall.com/lkrg/
Tu jest jego pokaz z konferencji jak zabija exploity zero day pod ubuntu: https://www.youtube.com/watch?v=tOiPM692DOM
Malo tego. Jest to zwykly modul, ktory sobie mozesz wlaczyc pod kazdym linuxem, nawet pod RedHatem, ktory nie "dotyka" kernela i RedHatowskiej licencji/supportu. Uzywalem, sprawdzalem dziala rewelacyjnie. Piekne jest to, ze taki projekt rozwija rodak. Dodam jeszcze, ze w tym projekcie bral udzial (w sensie pomocy) Brad Spengler oraz jakis czlonek z PaX Team. Tu masz link do artykulu w PL: https://zaufanatrzeciastrona.pl/post/linux-kernel-r … i-exploitami/

Ten modul dziala bez zadnego problemu z SELinuxem ! Taka "mieszanka" juz znacznie podnosi bezpieczenstwo w Linuxie. Dodatkowo uzytkownik powinien byc zmapowany do uzytkownika SELinux user_u.

Pozdro,

Ostatnio edytowany przez bryn1u (2018-08-14 13:39:33)

Jacekalex napisał(-a):

Oj tam, oj tam.

Linux zawsze trzyma rozsądną odległość od realnych zagrożeń.

To sa podstawy podstaw

które eliminują 98% znanych zagrożeń.

Systemy bazujące na GCC kiedyś nie używały nawet stack-protector, PIE ani SPP, kiedy to stało się potrzebne, już używa.

Kolejne mechanizmy,mkiedy będą odpowiednio przetestowane, też się pojawią, spokojna czaszka.

Gentoo ma własny zestaw łatek hardened do GCC, i go stosuje.

Lepiej oddziel marketingową religię HBSD, od rzeczywistości.

Ta rzeczywistość pokazuje, że każdy system moze być bezpieczny, o ile nie pozostawia się w nim celowo backdoorów, jak w Windowsach, i robią go ludzie poważni
a nie gendero-ćpuny, jak w Redmond.

Tyle lat były rozsiewane brednie o tym że "na Linuxa nie ma wirusów bo nikt go nie używa", aa z Google pokazało Androida, który już pracuje na ponad 1,5 miliarda urządzeń a ma znacznie mniej realnych zagrożeń niż Windows 7/8/10.

PS:
https://www.phoronix.com/scan.php?page=news_item&am … GCC-8-Landing
Jak widać, GCC też nie stoi w miejscu, jakby chcieli fanboye BSD i Clanga.
W Debianie testing jest już:

Kod:

gcc version 8.2.0 (Debian 8.2.0-1)

I jeszcze jedna "straszna" wiadomość:
http://lkml.iu.edu/hypermail/linux/kernel/1808.1/03379.html
xD

Pozdro

Lepiej oddziel marketingową religię HBSD, od rzeczywistości.

Nie masz kompletnie pojecia o czym piszesz. Zobacz najpierw jacy ludzie go tworza i poczytaj troszke o tym, to wtedy moze zrozumiesz o czym pisze. Juz nie wspomne,  ze ludzie, ktorzy uzywali grsec przechodza na HBSD, a nie na "bezpiecznego" linuxa, ktory ma bez grsec gowno, a nie ochrone kernela przeciwko exploitom zero day. Po trzecie rozwiazania z grsec sa zaimplementowane w hbsd jak PaX, wiec z tego wynika, ze wedlug Ciebie grsec to tez marketing. Chocby nawet porownaj ASLR w Linuxie i w BSD :P  Po 4 poczytaj o secadm, po 5 poczytaj o jailu w hbsd, ktorego grsec moze pozazdroscic i po 5 nie chce mi sie rozpisywac bo i tak widzisz to co chcesz widziec.
Jacy zas fanboye clanga. Clang ma wiecej mechanizmow bezpieczenstwa niz gcc, oprocz tego zobacz benchmarki w wydjanosci kompilacji to sobie sam odpowiesz. I jak widac clang  jeszcze mniej stoi w miejscu niz gcc :P Dlatego, ze cos jest lepsze i nie jest po twojej mysli to kojarzy sie z fanboyem ? Wykazujesz sie po prostu ignorancja.
Co do windowsa 10 to poczytaj jakie ma technologie zabeczpieczenia kernela przeciwko zero day, a pozniej porownaj z linuxem.

bryn1u to zapuść lynisa na bsd i dawaj output, mój debian a mam głęboko w doopie jakieś grube dłubanie i szczególne utwardzanie swojego desktopa:

[+] Kernel Hardening
------------------------------------
  - Comparing sysctl key pairs with scan profile
    - fs.protected_hardlinks (exp: 1)                         [ OK ]
    - fs.protected_symlinks (exp: 1)                          [ OK ]
    - fs.suid_dumpable (exp: 0)                               [ OK ]
    - kernel.core_uses_pid (exp: 1)                           [ OK ]
    - kernel.ctrl-alt-del (exp: 0)                            [ OK ]
    - kernel.dmesg_restrict (exp: 1)                          [ OK ]
    - kernel.kptr_restrict (exp: 2)                           [ OK ]
    - kernel.randomize_va_space (exp: 2)                      [ OK ]
    - kernel.sysrq (exp: 0)                                   [ OK ]
    - kernel.yama.ptrace_scope (exp: 1 2 3)                   [ OK ]
    - net.ipv4.conf.all.accept_redirects (exp: 0)             [ OK ]
    - net.ipv4.conf.all.accept_source_route (exp: 0)          [ OK ]
    - net.ipv4.conf.all.bootp_relay (exp: 0)                  [ OK ]
    - net.ipv4.conf.all.forwarding (exp: 0)                   [ OK ]
    - net.ipv4.conf.all.log_martians (exp: 1)                 [ DIFFERENT ]
    - net.ipv4.conf.all.mc_forwarding (exp: 0)                [ OK ]
    - net.ipv4.conf.all.proxy_arp (exp: 0)                    [ OK ]
    - net.ipv4.conf.all.rp_filter (exp: 1)                    [ OK ]
    - net.ipv4.conf.all.send_redirects (exp: 0)               [ OK ]
    - net.ipv4.conf.default.accept_redirects (exp: 0)         [ OK ]
    - net.ipv4.conf.default.accept_source_route (exp: 0)      [ OK ]
    - net.ipv4.conf.default.log_martians (exp: 1)             [ DIFFERENT ]
    - net.ipv4.icmp_echo_ignore_broadcasts (exp: 1)           [ OK ]
    - net.ipv4.icmp_ignore_bogus_error_responses (exp: 1)     [ OK ]
    - net.ipv4.tcp_syncookies (exp: 1)                        [ OK ]
    - net.ipv4.tcp_timestamps (exp: 0 1)                      [ OK ]
    - net.ipv6.conf.all.accept_redirects (exp: 0)             [ OK ]
    - net.ipv6.conf.all.accept_source_route (exp: 0)          [ OK ]
    - net.ipv6.conf.default.accept_redirects (exp: 0)         [ OK ]
    - net.ipv6.conf.default.accept_source_route (exp: 0)      [ OK ]

[+] Security frameworks
------------------------------------
  - Checking presence AppArmor                                [ FOUND ]
    - Checking AppArmor status                                [ ENABLED ]
  - Checking presence SELinux                                 [ NOT FOUND ]
  - Checking presence grsecurity                              [ NOT FOUND ]
  - Checking for implemented MAC framework                    [ OK ]

 Lynis security scan details:

  Hardening index : 73 [##############      ]
  Tests performed : 215
  Plugins enabled : 1

Ostatnio edytowany przez hi (2018-08-27 18:17:22)

A jaką masz kartę muzyczną?

https://www.freebsd.org/doc/handbook/sound-setup.html
https://www.freebsd.org/cgi/man.cgi?sound

Kudzu napisał(-a):

(...)
Dźwięk na głośnikach działa super. Na słuchawkach jest głucha cisza. Sprawdzałem w pavucontrol i xfce4 mixerze, nic nie było na mute.
Przebudowałem OSS'a, zbudowałem z portów pulseaudio. Nic to nie dało.
Dodam, że próbowałem na 11.2-RELEASE.
Szkoda też, że nie ma opcji oglądania Netflixa na fbsd (o ironio;)) inaczej niż z maszyny wirtualnej z linuxem/windowsem :)

Gdyby tylko działał dźwięk na słuchawkach, to zamieniłbym Debka na fbsd (to mój laptop służbowy :))

Czesc,

to i prosta i trudna kwestia zarazem.

Prosta bo jak masz odpowiedni wpis w /boot/device.hints to po prostu dziala, trudna, bo najpierw trzeba goznalezc :)

Przykladowo ja na ThinkPad T420s potrzebuje takiego wpisu w /boot/device.hints jak ponizej:

# ThinkPad T420s SOUND ON HEADPHONES
hint.hdaa.0.nid31.config="as=1"
hint.hdaa.0.nid25.config="as=1 seq=15 device=Headphones mute=0 misc=0"
hint.hdaa.0.nid28.config="as=1 seq=15 device=Headphones mute=0 misc=0"

Tutaj tez gosc opisal jak to robil dla swojego ThinkPad X1 6th GEN:
https://www.youtube.com/watch?v=ki9z55hiRbQ

Komenda ponizej tez bedzie bardzo przydatna (zeby zobaczyc co jest ustawione i na co sie ustawilo):

# sysctl dev.hdaa

Genralnie metodologia jest taka ze przegladasz wynik sysctl dev.hdaa nastepnie ustawiasz to co Ci sie wydaje ze powinienes ustawic w /boot/device.hints nastepnie reboot i sprawdzasz czy dzwiek jest, jak jest to wygrales a jak nie to wstawiasz co innego do /boot/device.hints i probujesz ponownie.

Gosc na tym filmie dosc dobrze to opisal.

Ostatnio edytowany przez vermaden (2018-12-13 12:10:20)

Stało sie. HardenedBSD-12

http://installer.hardenedbsd.org/pub/HardenedBSD/re … BLE-v1200058/

Among those improvements are:

The first public release of hardened/12-stable/master branch, which contains lots of security improvements over 11-STABLE.

Non-Cross-DSO Control-Flow Integrity (CFI) for applications on amd64 and arm64. At this time, CFI is not applied to the kernel. More info on CFI is below.
Jailed bhyve.
Per-jail toggles for unprivileged process debugging (the security.bsd.unprivileged_process_debug sysctl node).
Spectre v2 mitigation with retpoline applied to the entirety of base and ports.
Symmetric Multi-Threading (SMT) disabled by default (re-enable by setting machdep.hyperthreading_allowed to 1 in loader.conf(5)).
Migration of more compiler toolchain components to llvm's implementations (llvm-ar, llvm-nm, and llvm-objdump).
Compilation of applications with Link-Time Optimization (LTO).
Non-Cross-DSO CFI
Non-Cross-DSO CFI is an exploit mitigation technique that helps prevent attackers from modifying the behavior of a program and jumping to undefined or arbitrary memory locations. Microsoft has implemented a variant of CFI, which they term Control Flow Guard, or CFG. The PaX team has spent the last few years perfecting their Reuse Attack Protector, RAP. CFI, CFG, and RAP all attempt to accomplish the same goal, with RAP being the most complete and effective implementation. Clang's CFI is stronger than Microsoft's CFG and PaX Team's RAP is stronger than both CFI and CFG. RAP would be a great addition to HardenedBSD; however, it requires a GPLv3 toolchain and is patented.

Clang's CFI requires a linker that supports Link-Time Optimization (LTO). HardenedBSD 12-STABLE ships with lld as the default linker. All CFI schemes have been enabled for nearly all applications in base. Please note that any application that calls function pointers resolved via dlopen + dlsym will require the cfi-icall scheme to be disabled.

Ostatnio edytowany przez bryn1u (2018-12-18 14:46:16)

bryn1u napisał(-a):

... Nawet Selinux nie chroni w pelni bo np nie chroni przed shellcode, nie wykryje Ci roznych sztuczek w pamieci ram. ...

Jako zwolennik tego mechanizmu czuję się w obowiązku do sprostowania tego stwierdzenia :)
Rzecz w tym, że ogólnie rzecz ujmując to SELinux chroni przed shellcode ale w tym zdaniu jest też trochę prawdy i warto by ją oddzielić.
Jeżeli celem shellcode jest np. uruchomienie powłoki z uprawnieniami innego użytkownika to:
- shellcode musi zmienić id użytkownika i uruchomić ten program i to SElinux kontroluje i może blokować w zależności od reguł "transition"
- SELinux nie kontroluje tego co dzieje się w przestrzeni użytkownika (właściwie to procesu), czyli "sztuczki w pamieci ram" działają - efektem tego będzie to, że SELinux nie zablokuje np. buffer overflow, który jest sposobem na załadowanie shellcode, ale nie pozwoli na jego uruchomienie

Ogólnie to SElinux izoluje domeny, w których działają poszczególne procesy. Jeżeli w takiej domenie jest np. Apache to SELinux nie pozwoli mu wykonać syscall-i do których nie ma zezwolenia i nie zezwoli na przejście do innej domeny za pomocą funkcji systemowej, na którą ma zezwolenie ale nie ma na przejście do docelowej domeny.

A systemy takie jak GenodeOS, HelenOS, HaikuOS, OpenIndiana, RedoxOS można nazwać Unixami podobnymi do systemów BSD? I gdzie można sprawdzić ich udziały w rynku poza google statistic. Czy maja dużo mniej użytkowników względem tych trzech systemów BSD? Ostatnio czytałem na phoronix że wyszedł system Debian GNU Hurd i ktoś tam go skrytykował, że jeden człowiek zrobił więcej z systemem ToaruOS.
https://www.phoronix.com/forums/forum/software/bsd- … port-for-llvm

Ostatnio edytowany przez buster (2019-07-09 19:48:16)

Tak jest, tylko mi się ta grafika z 2015 roku nie chce powiększyć.

Projekt TrueOS (desktopowa wersja FreeBSD,  wcześniej znana jako DesktopBSD) był nieaktywny przez kilka miesięcy, a ostatnio zespół ogłosił, że projekt zostaje oficjalnie przerwany.

Open Letter to the TrueOS Community
TrueOS Discontinuation

Hey TrueOS Community! I just wanted to take a few minutes to address what some of you may have already guessed. With a heavy heart, the TrueOS Project’s core team has decided to discontinue the development of TrueOS for the foreseeable future. We’ll still be heavily involved in other Open Source projects like FreeNAS & TrueNAS CORE. We’re incredibly proud of the work we put into TrueOS and its predecessor, PC-BSD.

TrueOS source code will remain available on GitHub for others that may want to continue the work that we started so many years ago. I can’t explain just how much we appreciate you all being loyal fans of TrueOS and PC-BSD in the past. We’re confident that even though this is a hard decision, it’s also the correct decision because of the exciting new projects that we’re all becoming more involved in like TrueNAS CORE. If you have any questions don’t hesitate to ask.

https://www.truenas.com/TrueOS-Discontinuation/

https://klarasystems.com/articles/history-of-freebsd-unix-and-bsd/
https://klarasystems.com/articles/history-of-freebs … usl-lawsuits/
https://klarasystems.com/articles/history-of-freebs … s-of-freebsd/