-
Fototrend
Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.
Új hozzászólás Aktív témák
-
urandom0
senior tag
Viccesek ezek az OpenBSD-s srácok, egy tegnapelőtti e-mailben felvetették, hogy gzip-ről át kéne állni xz-re, abból is a v5.6.1-es verzióra, mert az biztonságos: https://marc.info/?l=openbsd-cvs&m=171200100510963&w=2
Nem sokkal később Theo de Raadt, az OpenBSD és az OpenSSH projektek alapítója, beküldött egy olyan e-módosítást, hogy "remove useless whitespace; from Jia Tan"
-
urandom0
senior tag
Lecseréltem az oprendszer a Raspberrymen.
Eredetileg Fedora IoT-ot akartam rá, de háromszori próbálkozásra sem sikerült elindítanom az installját, aminek magától el kellett volna indulnia. Sebaj, gondoltam, úgyis kísérletezős kedvemben vagyok, feldobtam rá egy Devuant. Oké, frankó, működik, és nagyon gyors, csak hát na... az összes disztróm systemd-es, vannak systemd service fájlaim, én systemd-re vagyok berendezkedve, úgyhogy gondoltam, legyen inkább Debian (Raspberry Pi OS), mégis csak ez a hivatalosan ajánlott rendszer RPi-re.
Ez is felment, frankó, működik, elkezdtem összerakni a dolgaim, Apache virtual hostok, radicale, stb., na a radicale elhasalt, egy csodálatos hibaüzenet (valami ilyesmi volt, hogy requests.exceptions.SSLError: HTTPSConnectionPool(host='www.url.com', port=443): Max retries exceeded with url: (Caused by SSLError(SSLError(336265225, '[SSL] PEM lib (_ssl.c:3837)')))) és fél méter traceback kíséretében (persze, ezt is úgy kellett kikönyörögni tőle, alapból csak az stdout-ra logol). Valószínűleg valami Python hiba lehetett, amit azóta javítottak, de Debian-ig még nem csorgott le a javítás.Na jó, mondom, a Debian nem a barátom, keressünk mást. Mivel úgyis RHEL-alapú rendszert akartam rá, elkezdtem vacillálni a Rocky és az AlmaLinux között. A Rocky jelen pillanatban népszerűbb, úgyhogy az ment rá.
Feltelepítettem, beállítottam a szokásos dolgokat, hozzáadtam az RPM Fusiont (ez hozza magával az EPEL-t is), és összeraktam a radicale szerverem, és most teljesen jól működik. Általános használat közben egy kicsit lassabb, mint Devuannal, illetve hát a dnf jóval lassabb, de legalább minden működik.
Egyetlen egy hibába futottam bele, segfaultot dob, ha kbdrate-tel állítgatom a billentyűzetet, de ez valami RPi specifikus hiba lehet, mert másnál is előjött már évekkel ezelőtt Raspbian alatt. -
Vladi
nagyúr
válasz
urandom0
#33996
üzenetére
nincs 3 életem, így is csomó hülyét kerülgetek.
Valamint az aktuális életfilozófiám: mivel én elmaradott faszi vagyok, csak azt hiszem el, amit a vaksi szememmel látok, süket fülemmel hallok és tompa agyammal gondolok. Akkor is ha ez nem ér fel a nagy céljaik igazságához.
-
-
válasz
bambano
#33986
üzenetére
Valoszinuleg utobbi miatt esett az xz-re a valasztas. A systemd felzabal mindent, korbe dependalnak egymasra, atlathatatlan az egesz, igy a tamadok felteteleztek, atcsuszik a kod.
Egyes feltetelezesek szerint nem is backdoor, hanem RCE - es mivel az sshd root kontextusban fut, a dalnak vege lett volna.
Az azert nem hagy nyugodni: ha egy Intel mernok nem futtat benchmarkokat es nem tunik fel neki, hogy tul sok CPU-t zabal az ssh, meddig terjed szet a kod?
-
bambano
titán
válasz
urandom0
#33980
üzenetére
az xz egy annyira fontos szoftver, hogy egyáltalán nem az, még egy debian is elgurul nélküle.
Az pedig továbbra is hiba, hogy systemd jellegű óriás bináris blobok vannak a mostani disztrókban, és ész nélkül használják is azt. Jól láthatóan az alapelvtől való eltérés lényegesen elősegítette a kendácsolást.
-
urandom0
senior tag
Az xz backdoorhoz még annyit, hogy valaki csinált egy idővonalat, ami összefoglalja Jia Tan "fantasztikus" munkásságát, illetve néhány más érdekességet is lehoz: https://boehs.org/node/everything-i-know-about-the-xz-backdoor
Ebből is látszik, hogy már 2021-ben próbált ő backdoort csempészni a libarchive kódjába, illetve később több kamufiókkal együtt próbáltak nyomást gyakorolni, hogy a patchjeik kerüljenek bele a kódba, azután pedig el akarták érni, hogy az xz projekt vegyen be új fejlesztőket, ami sikerült is, így került be Jia Tin a fejlesztésbe. Az egyik nyomásgyakorló, "Jigar Kumar" szomorúnak tartotta (akit se előtte, se azóta nem látott senki), hogy az xz projekt nem halad, mert a jelenlegi maintainer (Lasse Collin) elvesztette az érdeklődését a projekt iránt, vagy nem törődik többé a karbantartással.
Biztos, hogy szervezett akció volt ez az egész, nem kizárt, hogy valamelyik kormányzat áll mögötte. -
urandom0
senior tag
Persze, jó a nyílt forráskód, én a kényesebb adataimat nem is bízom zárt forráskódú programokra.
De ez a történet nem ilyen egyszerű. Itt emberi hibák is bőven belejátszottak abba, hogy ez megtörténhetett. Az egyik ilyen az volt, hogy Lasse Collin volt az xz egyedüli fejlesztője, aki mellékállásban, hobbiként csinálta, és aki egyébként mentális gondokkal is küzdött. Ami mondjuk nem meglepő, ha azt vesszük, hogy az xz egy kurva fontos szoftver az egész open source közösségben, és nyilván egy ilyen fontos szoftver fejlesztőjeként nem kis nyomás van rajtad.
Lehet, hogy ez az egész nem történt volna meg, ha a nagy cégek (Red Hat, Suse, IBM, Intel, Canonical...) kicsit jobban odafigyelnek az xz projektre, és nem egyetlen emberre bízzák az egészet. Jó lenne, ha ezek a cégek prioritizálnák a dolgaikat, és nagyobb hangsúlyt fektetnének a fontos szoftverekre, ahelyett, hogy a libadwaitát reszelgetik, hogy bugyirózsaszín ablakkeret mellé babakéket is be lehessen állítani.
Itt azért nem érvényesült a manyeyeball, mert nem volt manyeyeball. A backdoor sem azért derült ki, mert valaki vizsgálgatta a forráskódot, hanem mert a bináris túl nagy CPU loadot generált.
És mondhatnám azt, hogy zárt forráskódú programba eleve nem tud bekommitolni senki sem backdoort. De teljesen mindegy, szerintem ez a mostani egy tipikusan olyan dolog, amit nem lehet kivédeni. -
urandom0
senior tag
válasz
bambano
#33977
üzenetére
Nem mondom, hogy nincs igazság abban, amit mondasz. Az tény, hogy a systemd marha nagyra nőtt, és ott van már PID1-ben majdnem az egész Linux, és ez nem biztos, hogy jó így.
De ez itt nem a systemd hibája volt. Ha bele akarunk menni, megkérdezhetjük, hogy miért gondolták jó ötletnek azt, hogy az sshd dependáljon a systemd-re? Én nagyjából tudom (mert utánaolvastam), azért, mert a systemd által nyújtott sd_notify() fv-t használja arra, hogy értesítse a systemd-et arról, amikor elindult.
Nem lehetett-e volna megoldani valami jó kis POSIX cuccal, vagy UNIX socket domainnel?
De biztos meg lehetett volna, de szerintem teljesen jogos volt a maintainerek törekvése arra, hogy ha már úgyis systemd-es környezetben fog futni az sshd, akkor használjuk már ki a systemd szolgáltatásait (ezzel systemd függővé tenni az sshd-t), mert hogy ennek előnyei is vannak. Nyilván, ha nem lennének előnyei, nem használnánk.
Tehát itt volt egy döntés a Debian és néhány másik disztribúció részéről, aminek lettek következményei. De szerintem ebbe nem nagyon lehet belekötni. -
Vladi
nagyúr
válasz
urandom0
#33970
üzenetére
ugye, ugye..! mire nem jó a transzparencia. rémlik, hogy valaki anno írt erről blogot, hogy a linux nem elsősorban azért biztonságos, mert kevesen használják.
egyébként az egyetlen valamirevaló disztró ami még sysvinitet használ az az antix, lehet arra fogok átállni.
-
bambano
titán
válasz
urandom0
#33974
üzenetére
A unix úgy született, hogy megpróbáltak komplex operációs rendszert írni, de nem sikerült. Ekkor lett az alapelve, hogy keep it stupid and simple.
A systemd teljesen egyértelműen szembemegy ezzel az alapelvvel, nagy hiba volt integrálni a disztrókba.
Minél több szemetet integrálsz az oprendszerbe, annál több támadási vektort hagysz benne. -
urandom0
senior tag
válasz
urandom0
#33969
üzenetére
Na még ennyit: a backdoort Andreas Freund - Microsoft dolgozó - vette észre, amikor egy friss xz csomaggal ellátott Debian Sides gépre be akart jelentkezni SSH-n keresztül. A bejelentkezés irreálisan nagy CPU terhelést okozott, és a Valgrind hibákat dobott, ezekből vette észre, hogy valami nem okés. Itt az e-mailje: [link]
-
urandom0
senior tag
válasz
urandom0
#33969
üzenetére
Még egy érdekesség, a Jia Tan által beküldött commitban van egy szándékos hiba. Ezt úgy idézte elő, hogy az egyik függvény (my_sandbox) elé berakott egy .-ot: https://git.tukaani.org/?p=xz.git;a=commitdiff;h=328c52da8a2bbb81307644efdb58db2c422d9ba7
Ez megakadályozta a Landlock nevű sandboxing működésbe lépését, így az xz olyan erőforrásokhoz is hozzáférhetett a rendszeren, amikhez alapvetően nem szabadott volna.
Lasse Collin commitja javította a hibát. -
urandom0
senior tag
Egyébként az elmúlt ~2 évben 750 commitja volt az xz projekthez a backdoort elhelyező jóembernek (név szerint Jia Tannak, aki valószínűleg Szingapúrban vagy annak közelében él), így lehet, hogy fognak még backdoort találni korábban kiadott verziókban is. Folyamatosan nézik át a régebbi kódokat, de ez elég nehéz munka, eltart egy darabig.
-
-
urandom0
senior tag
válasz
sh4d0w
#33961
üzenetére
Csak a development verziók vannak bajban, meg a rollingok, azok közül se mind. Ubuntu 22.04, 23.10, Linux Mint, Debian Stable, Fedora 39, OpenSuse Leap nem érintettek.
Fedora 41, Rawhide, OpenSuse TW, Friss Kali érintettek, Debianból testing, unstable és experimental lehet érintett.Kivéve, ha nincs esetleg valamelyik régebbi xz-ben is backdoor.
-
urandom0
senior tag
válasz
Mr Dini
#33959
üzenetére
Nem tudtam még alaposabban utánajárni, most is rokonokhoz megyünk épp. De kb. ezt írják a legtöbb helyen:
"Remember to update your systems.
This backdoored version was in OpenSUSE Tumbleweed, Arch, Debian Testing and Sid, Fedora Rawhide (and maybe Fedora 40 Beta), Ubuntu 24.04 development versions, NixOS Unstable, and other distros. But not all distros with the backdoored version are believed to be vulnerable.
However, the backdoor was added by a maintainer who had been committing for years, so it may be possible that even older versions may be vulnerable in some way (but this is only conjecture at this point)."
Az utolsó mondat még fontos lehet. Lényeg, hogy aki tud, frissítsen.
Én reggel lefrissítettem a rendszereim, Debian stable-hez és Fedora 39-hez nem láttam jönni új xz csomagot (ugye ők nem érintettek), OpenSuse TW-hez viszont igen. -
válasz
urandom0
#33955
üzenetére
Az Arch elvileg nem volt közvetlen érintett, mert a supply chain attack fejlesztő berakta feltételnek, hogy csak akkor kerüljön be a kártékony patch, ha deb, vagy rpm build megy. Szerencsére viszonylag hamar észrevették, szóval csak a Debian Sid, fedora rawhide és társai voltak érintettek.
De kemény story, igen. Sajnálom, mert az lzma a kedvenc tömörítési eljárásom. Így biztosan meg fog inogni az emberek hite a szoftver amúgy elképesztő képességeiben.
-
urandom0
senior tag
válasz
kovaax
#33957
üzenetére
Right now no Debian stable versions are known to be affected. Compromised packages were part of the Debian testing, unstable and experimental distributions, with versions ranging from 5.5.1alpha-0.1 (uploaded on 2024-02-01), up to and including 5.6.1-1. The package has been reverted to use the upstream 5.4.5 code, which we have versioned 5.6.1+really5.4.5-1.
Users running Debian testing and unstable are urged to update the xz-utils packages.
https://lists.debian.org/debian-security-announce/2024/msg00057.html
-
urandom0
senior tag
válasz
urandom0
#33955
üzenetére
Olvasnivaló:
https://news.ycombinator.com/item?id=39868673
https://news.ycombinator.com/item?id=39868673
https://www.openwall.com/lists/oss-security/2024/03/29/4
Izgalmas történet, bár nem tudom, mennyi az igazság belőle. Úgy tűnik, hogy egy olyan karbantartó csempészett backdoort az xz-be, aki évek óta hozzájárul a feljesztéséhez.
Azt rebesgetik, talán valamelyik szervezet embere lehet a tettes (ki tudja?). Mindenesetre a Github accountja (és egy másik emberé is) fel lett függesztve.
A végcél valószínűleg az lehetett, hogy hátsó ajtót nyissanak az SSH-ban. -
urandom0
senior tag
Kicsit nyomatékosabban kell ezt csinálni.
Na szóval, veszélyes backdoort találtak az xy utilsban, ami kb. az összes disztrón jelenlévő xz tömörítő segédprogramjában. Nagyon sok disztró érintett, Red Hat származékok, Debian, Suse, Arch, stb.
A lényeg, hogy mindenki toljon egy frissítést a rendszerére/rendszereire, minél előbb!!https://archlinux.org/news/the-xz-package-has-been-backdoored/
https://www.darkreading.com/vulnerabilities-threats/are-you-affected-by-the-backdoor-in-xz-utils
https://www.theregister.com/2024/03/29/malicious_backdoor_xz/
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
-
urandom0
senior tag
-
janos666
nagyúr
Mármint StrongsWAN vagy WireGuard helyett?
Utóbbi is tök egyszerű lenne, csak OCD-s vagyok, ezért úgy akarom megcsinálni, hogy inkább a szerver oldalon kelljen csak telepítgetni/konfigolni, aztán onnantól kintről bármi elérje extra szoftver nélkül (akár Android, akár iOS telefon is, nem csak Windows, stb).
Na ez lenne az IKEv2, csak az elég bonyolult ahhoz, hogy nem jövök rá jó leírás nélkül, a disztrós wiki-k pedig úgy látszik valamennyire disztró függőek is, illetve könnyű elveszni a leírásokban, mert ezer féle dolgot lehet csinálni (ilyen-olyan tunneling, eltérő login mód...). -
janos666
nagyúr
Tudna valaki segíteni Windows kompatibilis StrongsWAN IKEv2 VPN szerverrel Gentoo-n?
Próbáltam követni a Gentoo és az Arch Wiki-ket is, de egyikkel sem értem célba. Eleve fura, hogy a két leírás közül az első mind a StrongsWAN, a második mind az IPSec mappákba teszi a certificate és config file-okat is (a másikhoz nem nyúlnak).
Jobb lenne cert file-al bejelentkezni jelszó helyett (ahogy az Arch leírása mutatja).
Csak saját használatra kéne és csak az itthoni szervert akarom elérni távolról, nem kell internetet is tunnel-ezni. De nem akarok külön Wireguard klienst telepíteni Windows-ra. -
Sziasztok!
Az alábbi a /proc/fs/cifs/DebugData file tartalma.
Ebből kiderül, hogy encrypted az adatforgalom, vagy sem?A Security type: RawNTLMSSP alapján ez nem az, de már kezdek elveszni az egészben.
A szerver oldalon az smb.conf-ban megadtam ezeket:
server min protocol = SMB3
server signing = required
client smb encrypt = desired
Erre a szerverre csatlakozom távoli gépről, és annak a debugdata file-ja van itt alább.Display Internal CIFS Data Structures for Debugging---------------------------------------------------CIFS Version 2.29Features: DFS,FSCACHE,STATS,DEBUG,ALLOW_INSECURE_LEGACY,WEAK_PW_HASH,CIFS_POSIX,UPCALL(SPNEGO),XATTR,ACLCIFSMaxBufSize: 16384Active VFS Requests: 0Servers:Number of credits: 389 Dialect 0x311 signed1) Name: _ipcímem_ Uses: 1 Capability: 0x300047 Session Status: 1 Security type: RawNTLMSSPTCP status: 1 Instance: 1Local Users To Server: 1 SecMode: 0x3 Req On Wire: 0 In Send: 0 In MaxReq Wait: 0 SessionId: 0x818dec87User: 0 Cred User: 0Shares:0) IPC: \\__webcímem___\IPC$ Mounts: 1 DevInfo: 0x0 Attributes: 0x0PathComponentMax: 0 Status: 1 type: 0 Serial Number: 0x0Share Capabilities: None Share Flags: 0x0tid: 0x4651b40e Maximal Access: 0x1f00a91) \\__webcímem___\_share_ Mounts: 1 DevInfo: 0x22 Attributes: 0x1006fPathComponentMax: 255 Status: 1 type: DISK Serial Number: 0x859b267eShare Capabilities: None Aligned, Partition Aligned, Share Flags: 0x0tid: 0x60aca1fb Optimal sector size: 0x200 Maximal Access: 0x1f00a9MIDs:Server interfaces: 10) Speed: 1000000000 bpsCapabilities:IPv4: 192.168.0.2 -
daninet
veterán
Sziasztok!
Tumbleweed, nvidia kártya a zárt driverrel. Két monitorom van, az egyik hdmi a másik display port. Teljesen random, hogy melyiket inicializálja indításnál először és amikor a DP monitorral teszi (ami az elsődleges képernyő) akkor a másodlagos képernyő üres marad, a widgetjeim nem jelennek meg ott, a háttérkép sem. Tudok ablakokat oda húzni, de minden panelemet rádobálja az elsődleges monitorrra.
Csak akkor jó a desktop, ha először a hdmi monitort inicializálja ami a másodlagos, majd a DP monitort ami az elsődleges. Lehet ezt valahogy valami konfiggal erőltetni? -
kovaax
őstag
válasz
Longeye
#33940
üzenetére
Mivel 1 felhasználó van, annak 1000:1000 lesz az uid:gid, és installkor ugyanazt adom meg, mint előzőleg, úgyhogy nem. Mondjuk install előtt a konfigok nagy részét is törölni szoktam, hogy totál tiszta lappal induljak, az új verzió "adottságainak" megfelelően. Felcsatolni se kell, mert particionáláskor megadom, hogy /dev/sda4 a /home, ne legyen formázva, és felhúzza automatikusan.
-
Longeye
tag
6-7 éve történt (még nagyon tapasztalatlan voltam, első Linux telepítéseim egyike), hogy egy teszt-szerveren nem tudtam pénteken befejezni a munkát, így létrehoztam egy joe felhasználót, joe jelszóval. Ugyan ki próbálkozna feltörni, pláne egy eldugott IPÜ címen lévőt.
Úgy alakult, hogy hétvégén nem jutottam hozzá, így rá se néztem.
Hétfőn már bent is volt valaki. Megváltoztatta a jelszót és tele írta a 2GB-os /home partíciót. Ennyit tudott csinálni, mert be volt kapcsolva a noexec. Hasonló okokból érdemes persze a /tmp-re és /var/tmp-re is bekapcsolni, de otthoni környezetben szerintem nincs akkora jelentősége.Akkor leírom a másik történetet is. Ez is régen történt.
Egyik felhasználó folyton átmozgatta a közös megosztásban lévő mappákat. Össze-vissza cserélgette. Szerettük volna kideríteni, ki volt. Bekapcsoltam Samba-ra az összes logot. Még azt is feljegyezte, mikor melyik mappába lépett be valaki és mit nyitott meg. Nos, közel 800 felhasználónál nem volt túl jó ötlet. 2 nap alatt megtelt a /var/log partíció. A rendszer reklamált ugyan miatta, de nem állt le. Ha minden egy partíción van, az kicsit kellemetlenebb lett volna.DE, otthoni környezetben mindez nem túl valószínű, hogy megtörténik.
Jah! És persze ez mind az én hülyeségem miatt volt.
-
Viszont most a Fedorat én is úgy telepítettem, hogy a /var, /var/tmp és /tmp külön partíciókon vannak. Ezekre lehet értelme fstabban noexecet, vagy más jellemzőt tenni?
Linux kezdőben nem merem megkérdezni, mert szerintem onnan kiküldenének ezzel a kérdéssel.
-
válasz
Longeye
#33929
üzenetére
Asztali gépet én így telepítek magamnak leggyakrabban:
/boot/efi - 1gb (overkill)
/ - 50 gb
swap - 10 gb(32 giga ramom van, bőven overkill)
/home - maradék hely és luks2Van olyan rendszer, ami automatikus particionálásnál mindent a rootba rak, meg talán csinál 1 giga swapot. Szerintem asztali felhasználásnál nem szükséges bonyolítani.
Fs: ext4, kivéve efinek fat32.
-
-
Longeye
tag
Köszönöm! Ok, értem.
A 2 és 20 GB-okat szerverre írtam. Ott nem egy tábla csokiba kerülnek a háttértárak. Nem az otthoni rendszereimre gondoltam, hanem a munkahelyi szerverekre.
Nem kifejezetten a helytakarékosság miatt osztom fel, hanem első sorban biztonsági okokból.Ezért is kérdezek, mert a saját desktop környezetemnél nem érzem szükségességét ennek. Ez nem lesz kiakasztva publikus fix IP címmel az Internetre és főleg nem 24 órában. A szerverek egy része viszont igen.
-
válasz
Longeye
#33923
üzenetére
asztali gép esetén minden a home-on lesz, böngésző cachetől, a letöltött cuccaidon át a fotókig.
nálam 150GB, abből 85 foglalt
a rooton 44GB cucc van, de nyilván függ attól mennyi mit telepítesz föl.
ma, amikor egy tábla csoki 250GB SSD, én nem bohóckodnék 2 meg 20GB-kkal -
Longeye
tag
Köszönöm a válaszod!
Ha a /home-ot külön teszem, mennyit hagyjak a root-nak (/)?
Szerveren a /home-nak 2GB-ot szoktam max adni és ott a /srv-hez, vagy az oda felcsatolt mappákhoz rendelek sokat.
A root-nak 20GB-ot szoktam adni, de az is bőven túlzás, mert a /tmp, /var/tmp, /var/log, /var/spool, var/cache is mennek külön partíciókra és így még a harmada sem szokott elfogyni.
Nem tudom, hogy mire kell figyelni desktop környezetben.2017, az nem semmi! Én kb. azóta kezdtem el Linux szervereket üzemeltetni.
-
válasz
Longeye
#33921
üzenetére
szia
nálam ha lehetőség van rá, akkor a /home egy külön meghajtón van, a /tmp meg mindig RAM disk (letöltési mappának használom ), de ennyi.
normál asztali felhasználással a /var-ba egyszerűen nem kerül annyi adat, hogy azt érdemes lenne kiszervezni.az én fő gépem egy 2017-ben telepített Arch.
a /var most úgy 20GB, hogy abból 14 a /var/lib/docker (esetleg ha sokat dockerezel, akkor ezt a mappát érdemes elköltöztetni) -
Longeye
tag
Sziasztok!
Linux szervereket üzemeltetek már néhány éve, de csak tavaly év végén jutottam el odáig, hogy desktop környezetként is elkezdjem használni.
Szervernél mindig felosztom a háttértárat úgy, hogy pl. a /var/log, a /tmp, a /var/tmp, stb. - nem ragoznám tovább, úgyis tudjátok - külön partícióra kerüljön. Meg persze a tulajdonságait is beállítom ezeknek a partícióknak (nosuid, nodev, noexec, noatime, nodiratime). Természetesen nem ész nélkül...minek hol van értelme.Ez a séma, amit használok, már kétszer is kihúzott a bajból.
A kérdésem az lenne, hogy érdemes ezt desktop környezetben is így csinálni, vagy fölösleges. Egyí felhasználós, a gépet csak én használom, más nem jelentkezik be rá. Én nyilván, a szervereimre bejelentkezek róla, de ennyi.
Érdekelne a tapasztalatotok! Előre is köszönöm!
-
urandom0
senior tag
Őszintén szólva, én ki szoktam kapcsolni a SELinuxot. Nem egyszer belefutottam már rejtélyes hibákba, amiket a SELinux okozott. Egyszer egy szimpla gcc-s fordítást tiltott le, máskor egy docker containerben kellett nyúlkálnom, az nem tetszett neki, volt hogy a céges LT2P VPN-t fogta meg...
De ha te nem ütközöl ilyen problémákba, akkor azt javaslom, hagyd bekapcsolva, alapbeállításon.A tűzfal beállítása megint csak használatfüggő. Nincsenek kötelezően tiltandó portok. Ha van olyan szolgáltatásod, ami kifelé hallgatózik, és nincs rá szükséged, akkor távolítsd el. Ha korlátozni akarod egyes szolgáltatások elérését, akkor csinálhatsz rá tűzfalszabályt. Illetve azt megcsinálhatod, hogy mindent deny-re állítasz, és csak azokat a portokat/programokat engedélyezed, amiket feltétlenül ki akarsz engedni (szerveren mi így szoktuk csinálni).
A szolgáltatások esetében megint csak azt tudom mondani, hogy amelyikre szükséged van, azt tartsd meg, amelyikre nincs, azt távolítsd el. Ez a systemd-analyze security parancs olyan szempontból szerintem kicsit megtévesztő, hogy igazából nem csinál mást, mint megmutatja, hogy a systemd által biztosított biztonsági feature-ök közül mennyit használ ki az adott service. Ha ezt optimalizálni szeretnéd, csak úgy lehetne megtenni, ha mélységében ismernéd a systemd-et, és az adott service-eket is, mindet egyesével. Ez azért nem kis munka, ráadásul van olyan service, aminél beállítasz egy adott opciót, és két hét múlva, ha mondjuk be akarsz dugni egy pendrive-ot, akkor jön elő, hogy nem működik...
Ahogy látom, elég sok virtualizáláshoz kapcsolódó szolgáltatásod van. Ha nem virtualizálsz, akkor azokat tiltogasd le, aztán ha esetleg valami nem működne, akkor engedélyezed.
-
Viszont lenne egy kérdésem a systemd-vel kapcsolatban is, mert a Lynis arra is vertyog, hogy sok bennük az unsafe.
Van értelme ezekből párat kilőni, ami tuti, hogy felesleges?- Running 'systemd-analyze security'
- ModemManager.service: [ MEDIUM ]
- NetworkManager.service: [ EXPOSED ]
- abrt-journal-core.service: [ UNSAFE ]
- abrt-oops.service: [ UNSAFE ]
- abrt-xorg.service: [ UNSAFE ]
- abrtd.service: [ UNSAFE ]
- accounts-daemon.service: [ MEDIUM ]
- alsa-state.service: [ UNSAFE ]
- auditd.service: [ EXPOSED ]
- avahi-daemon.service: [ UNSAFE ]
- chronyd.service: [ PROTECTED ]
- colord.service: [ EXPOSED ]
- crond.service: [ UNSAFE ]
- cups.service: [ UNSAFE ]
- dbus-:1.3-org.freedesktop.problems@0.service: [ UNSAFE ]
- dbus-broker.service: [ EXPOSED ]
- dm-event.service: [ UNSAFE ]
- emergency.service: [ UNSAFE ]
- firewalld.service: [ UNSAFE ]
- flatpak-system-helper.service: [ UNSAFE ]
- fprintd.service: [ MEDIUM ]
- fwupd.service: [ EXPOSED ]
- gdm.service: [ UNSAFE ]
- geoclue.service: [ EXPOSED ]
- getty@tty1.service: [ UNSAFE ]
- gssproxy.service: [ UNSAFE ]
- iscsid.service: [ UNSAFE ]
- iscsiuio.service: [ UNSAFE ]
- libvirtd.service: [ UNSAFE ]
- low-memory-monitor.service: [ MEDIUM ]
- lvm2-lvmpolld.service: [ UNSAFE ]
- mcelog.service: [ UNSAFE ]
- mdmonitor.service: [ UNSAFE ]
- nfs-idmapd.service: [ UNSAFE ]
- nfs-mountd.service: [ UNSAFE ]
- nfsdcld.service: [ UNSAFE ]
- packagekit.service: [ UNSAFE ]
- pcscd.service: [ UNSAFE ]
- plymouth-start.service: [ UNSAFE ]
- polkit.service: [ PROTECTED ]
- power-profiles-daemon.service: [ EXPOSED ]
- rc-local.service: [ UNSAFE ]
- rescue.service: [ UNSAFE ]
- rpc-gssd.service: [ UNSAFE ]
- rpc-statd-notify.service: [ UNSAFE ]
- rpc-statd.service: [ UNSAFE ]
- rpcbind.service: [ UNSAFE ]
- rtkit-daemon.service: [ MEDIUM ]
- sssd-kcm.service: [ EXPOSED ]
- sssd.service: [ EXPOSED ]
- switcheroo-control.service: [ EXPOSED ]
- systemd-ask-password-console.service: [ UNSAFE ]
- systemd-ask-password-plymouth.service: [ UNSAFE ]
- systemd-ask-password-wall.service: [ UNSAFE ]
- systemd-homed.service: [ MEDIUM ]
- systemd-hostnamed.service: [ PROTECTED ]
- systemd-initctl.service: [ UNSAFE ]
- systemd-journald.service: [ PROTECTED ]
- systemd-localed.service: [ PROTECTED ]
- systemd-logind.service: [ PROTECTED ]
- systemd-machined.service: [ MEDIUM ]
- systemd-oomd.service: [ PROTECTED ]
- systemd-resolved.service: [ PROTECTED ]
- systemd-rfkill.service: [ UNSAFE ]
- systemd-timesyncd.service: [ PROTECTED ]
- systemd-udevd.service: [ MEDIUM ]
- systemd-userdbd.service: [ PROTECTED ]
- thermald.service: [ UNSAFE ]
- udisks2.service: [ UNSAFE ]
- upower.service: [ PROTECTED ]
- uresourced.service: [ EXPOSED ]
- user@1000.service: [ UNSAFE ]
- vboxservice.service: [ UNSAFE ]
- vgauthd.service: [ UNSAFE ]
- virtinterfaced.service: [ UNSAFE ]
- virtlockd.service: [ UNSAFE ]
- virtlogd.service: [ UNSAFE ]
- virtnetworkd.service: [ UNSAFE ]
- virtnodedevd.service: [ UNSAFE ]
- virtnwfilterd.service: [ UNSAFE ]
- virtproxyd.service: [ UNSAFE ]
- virtqemud.service: [ UNSAFE ]
- virtsecretd.service: [ UNSAFE ]
- virtstoraged.service: [ UNSAFE ]
- vmtoolsd.service: [ UNSAFE ]
- wpa_supplicant.service: [ UNSAFE ] -
Üdv néktek,
Mivel ez már szerintem nem is kezdő téma, illetve a Fedora topik akut hullaszagot áraszt, így ide írom a kérdéseimet.
Fedorában az SELinuxot szükséges-e telepítés után állítani hétköznapi használatra, avagy sem?
Lynis audit csomag azt írta, hogy, bár aktív a firewalld, nincsen bekonfigurálva. Ez probléma lehet-e? Van-e valami útmutató, hogy hogyan tegyem, vagy mik a szükséges portok, amiket mindenképpen tiltsak le vele?
Mindkét programhoz telepítettem a neki megfelelő GUI-t, így azon keresztül tudom(-nám) őket konfigurálni. -
urandom0
senior tag
válasz
Ablakos
#33898
üzenetére
Tudtommal nincs jelentősége. Az fstabban megadott csatolásokból is mount ponintot csinál a systemd, ha kiadod a systemctl --type=mount parancsot, láthatod is a mount pointokat. Szerintem egyszerűbb beszúrni fstabba egy sort, mint egy .mount (és egyetleg egy .automount) fájlt megírni.
De felcsatolhatod rc.local-ban is (ebből is systemd service lesz), vagy írhatsz saját systemd service-t hozzá, de igazából legegyszerűbb az fstab-os megoldás.
Ha esetleg speciálisabb opciók kellenek, amik nem érhetők el fstabból (pl. adott systemd unit függőségeként csatolódjon fel a partíció), akkor érdemes rá systemd mount-ot írni. -
janos666
nagyúr
Most, hogy itt ez a BCacheFS, fontolgatom, hogy erre állítom át Btrfs RAID5-öt. Pár kérdés:
1: Vajon lesz a közeljövőben on-demand balance? (Ez csak az átállás alatt lenne érdekes.)
2: Lesz a közeljövőben online defrag?
3: Van tervben, hogy valami ZFS L2/ARC szerű caching mód is lesz a közeljövőben?
4: Ez gyorsabban olvas szekvenciálisan RAID5 módban, mint a Btrfs RAID5?Valamiért a Btrfs látszólag nem skálázódik olvasási sebességben a lemezekkel, sőt, valamiért már régóta ramaty a szekvenciális olvasás rendszeres defrag mellett is (~100Mb/s lenne a 7200RPM lemezek alja, és képes őket ennek kb. felével olvasni lemezenként, mikor szekvenciálisan olvasok egy nagy file-t, és így kijön olyan ~300MB/s öt darab lemezzel, ami hát... esküdni mernék, hogy valamikor 5-6 éve gyorsan olvasott!).
Vicces ez így, mert pl. ragaszkodok a defrag-hoz, de valamiért defrag-olva is lassan olvas a Btrfs RAID5, kb. olyan lassan, mint a ZFS olvasta a töredezett file-okat. De ZFS-nél ezt valamennyire kompenzálta a jobb cache-elés és scheduling (nyilván nem a csúcs szekvenciális olvasást növelte, de a nagy file-okkal kvázi-szekvenciális műveleteket látszólag gyorsított, pl. reszponzívabb volt a videókban ide-oda tekergetni).
Most pedig itt egy filrendszer, aminek a nevében is benne van, hogy *cache*, de csak sima writeback/writethrough, nem valami olyasmi cache-t használni, mint a ZFS L2/ARC.
Az is fura számomra, hogy miért nincs még on-demand balance a BCacheFS-ben, ha alapvetően képes rebalance-olni, vagy hogy miért nem említi a wiki/manpage oldala a defrag-ot, hogy hol áll a terveken, mert a COW filrendszer azért tud töredezni, és itt legalább nem tűnik olyan reménytelennek az online defrag, mint ZFS-nél, mégis köd és némaság övezi a defrag-ot (bár az on-demand balanc-ról se sok a hivatalos infó). -
Ablakos
őstag
A /media/ alatti folderem:
drwxrwxr-x 1 root user 0 febr 21 14:02 photo/
Ha felkapcsolom a távoli mappát:sudo mount -t cifs //192.168.200.3/photo /media/photo/ -o rw,vers=3.0,credentials=/root/.Credentials,gid=1000
elállítja a csoport bitet.
Ez lesz:drwxr-xr-x 2 root user 0 febr 21 14:16 photo/Mit kell még elkövetni, hogy a beállított csoport jog megmaradjon?
-
-
vicze
félisten
-
vicze
félisten
válasz
#79484416
#33901
üzenetére
Valószínű nem fog változni.
Bár OPAL 2.0-os SSD-t azt csináltam Linux-on, de az egy elég egyszerű dolog. Bár csak tesztnek és használva sose lett végülNekifutottam már 1-2x a LUKS TPM dolognak 4-5éve, de valamilyen támogatás minding elcsúszott. Vagy GRUB oldalon vagy LUKS oldalon. Mostanában nem néztem lehet már egyszerűbb és működik.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Látod, most is komolyan vettem a dolgot, egyből lecsekkoltam a Mint-et meg az LMDE-t.
Új hozzászólás Aktív témák
- BestBuy topik
- Androidos tablet topic
- Raspberry Pi
- Kerékpársportok
- Brave
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Melyik tápegységet vegyem?
- Android alkalmazások - szoftver kibeszélő topik
- Mibe tegyem a megtakarításaimat?
- Dual Mode-os IPS monitorral adott magáról életjelet a Gigabyte
- További aktív témák...
- Számlás!Steam,EA,Epic és egyébb játékok Pc-re vagy XBox!
- Eladó steam/ubisoft/EA/stb. kulcsok Bank/Revolut/Wise (EUR, USD, crypto OK)
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Eladó Steam kulcsok kedvező áron!
- HATALMAS AKCIÓK / MICROSOFT WINDOWS 10,11 / OFFICE 16,19,21,24 / VÍRUS,VPN VÉDELEM / SZÁMLA / 0-24
- Honor 90 Lite 256GB, Kártyafüggetlen, 1 Év Garanciával
- Csere-Beszámítás! Xbox One X 1TB Játékkonzol Olvass! Model 1787
- Telefon felvásárlás!! iPhone 11/iPhone 11 Pro/iPhone 11 Pro Max
- PROCASTER 40UNB700 40" 101cm televízió + Számla + Garancia
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged