Forum Debian Users Gang

[quote=Kudzu](...)
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 :))[/quote]
Czesc,

to i prosta i trudna kwestia zarazem.

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

Przykladowo ja na ThinkPad T420s potrzebuje takiego wpisu w [b]/boot/device.hints[/b] 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 [b]sysctl dev.hdaa[/b] nastepnie ustawiasz to co Ci sie wydaje ze powinienes ustawic w [b]/boot/device.hints[/b] nastepnie reboot i sprawdzasz czy dzwiek jest, jak jest to wygrales a jak nie to wstawiasz co innego do [b]/boot/device.hints[/b] 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/releases/amd64/amd64/ISO-IMAGES/HardenedBSD-12-STABLE-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)

[quote=bryn1u]... Nawet Selinux nie chroni w pelni bo np nie chroni przed shellcode, nie wykryje Ci roznych sztuczek w pamieci ram. ...[/quote]
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.