Премини към съдържанието
  • Добре дошли!

    Добре дошли в нашите форуми, пълни с полезна информация. Имате проблем с компютъра или телефона си? Публикувайте нова тема и ще намерите решение на всичките си проблеми. Общувайте свободно и открийте безброй нови приятели.

    Моля, регистрирайте се за да публикувате тема и да получите пълен достъп до всички функции.

     

Добри практики и Сигурност в Линукс


petie1

Препоръчан отговор

Нека в тази тема обсъждаме проблема със snap systemd и други подобни неддолюбвани неща за да не се пилее знанието по други теми

Линк към коментара
Сподели в други сайтове

  • Отговори 51
  • Създадено
  • Последен отговор

Потребители с най-много отговори

Мен ми е интересно какъв е проблема със systemd - при условие, че се ползва реално от всички?
Преимуществате пред SystemV мисля, че всеки, който е писал сървиси ги знае. А и има доста неща, който нямат никаква алтернатива в класическата INIT система

Линк към коментара
Сподели в други сайтове

преди 9 часа, borovaka написа:

Мен ми е интересно какъв е проблема със systemd - при условие, че се ползва реално от всички?
Преимуществате пред SystemV мисля, че всеки, който е писал сървиси ги знае. А и има доста неща, който нямат никаква алтернатива в класическата INIT система

Точно затова създадох темата

Линк към коментара
Сподели в други сайтове

  • 2 седмици по-късно...
на 5.09.2019 г. в 11:45, borovaka написа:

Мен ми е интересно какъв е проблема със systemd - при условие, че се ползва реално от всички?
Преимуществате пред SystemV мисля, че всеки, който е писал сървиси ги знае. А и има доста неща, който нямат никаква алтернатива в класическата INIT система

Проблемът със systemd е начина му на налагане и хилядите омотани депендънсита, разпиляни файлове и кофти документация. Systemd е наложен по един много фашистки начин, който не оставя на потребителя избор. А това противоречи с философията на отворения код да има избор. Освен това авторите са едни много неприятни типове,които дори не обръщат внимание на репортнатите бъгове. SystemD е Линукската версия на svchost.exe - и се опитва да превърне Линукс в Уиндоус, заради мързеливи и неграмотни потребители и администратори. Поредното доказателство че корпорациите съсипват всяка хубава идея. Solaris и AIX имат много по-читави решения за менажиране на сървисите - SMF за Соларис и SRC за AIX. 
 

Линк към коментара
Сподели в други сайтове

на 16.09.2019 г. в 21:08, ТерминалТора написа:

Проблемът със systemd е начина му на налагане и хилядите омотани депендънсита, разпиляни файлове и кофти документация. Systemd е наложен по един много фашистки начин, който не оставя на потребителя избор. А това противоречи с философията на отворения код да има избор. Освен това авторите са едни много неприятни типове,които дори не обръщат внимание на репортнатите бъгове. SystemD е Линукската версия на svchost.exe - и се опитва да превърне Линукс в Уиндоус, заради мързеливи и неграмотни потребители и администратори. Поредното доказателство че корпорациите съсипват всяка хубава идея. Solaris и AIX имат много по-читави решения за менажиране на сървисите - SMF за Соларис и SRC за AIX. 
 

А можеш ли да обясниш с какво по-точно SMF ( като идея говоря, не като имплементация ) е различен от SystemD? С SRC не съм се сблъсквал до сега, но SMF за мен е с почти 1-1 идея като  SystemD. Ако говорим за чистата имплементация, според мен INI стила на SystemD е по-четим от XML-a при писането на сървиси ( ако зависи от мен да го имплементирам - всичоко и навсякъде, за каквито и да е конфигурации трябва да е YAML, но това е друга тема ). 
Това за корпорациите също не го разбирам ( най-малкото си дал примери с IBM и ORACLE, като алтернативни решения ) - имаше алтернативи преди SystemD да се наложи ( Upstart/SystemV ).
Като цяло аз съм точно за налагане на стандарт на абстрацкия върху потребителите ( без значение - обикновен потребител/sysadmin etc. ). Това, че имаш стандарт на имплементация на сървиса - по никакъв начин не ти връзва ръцете за имплементацията на App-a, който ще стартираш през него. Дори напротив, дава ти стандартен и предиктивен начин на работа със ситемата ти.
При SystemV беше тотален shit положението, и сървиси се пишеха, на кой както му е кеф - predictability 0. 
За документацията - до някъде съм съгалсен, че е shit - но в скорошните release, man pages са ОК - поне според мен ( или аз съм привикнал с времето ).
Можеш ли да дадеш някакъв по-конкретен аргумент кое по-точно не е ОК според теб?
Колкото до авторите аз съм върл фен на Lennart Poettering - че маже кода, няма спор, ама идеите му са ОК, а и има кой да му оправя мазаляка ( в повечто случаи ). А и това пак е много-относително, защото примерно в kernel maling list-ите, ако проследиш дискусии - има доста по-големи мазаници, които се merge-ват upstream.
А това ,че има бъгове, които не са оправени много време, си а абсолютно нормална dev процедура. Ако, бъга няма директен security impact и не засяга голяма, част потребители - може да се отложи във времето, ако има лесен workaround - също. Ако за някой е голям проблем в тези случаи - може да си напише patch, или да наеме екип, който да го напише - за пример Facebook правят точно това, точно със SystemD и до колкото се сещам upstream-наха наскоро техни доработки.

Линк към коментара
Сподели в други сайтове

преди 2 часа, borovaka написа:

А можеш ли да обясниш с какво по-точно SMF ( като идея говоря, не като имплементация ) е различен от SystemD? С SRC не съм се сблъсквал до сега, но SMF за мен е с почти 1-1 идея като  SystemD. Ако говорим за чистата имплементация, според мен INI стила на SystemD е по-четим от XML-a при писането на сървиси ( ако зависи от мен да го имплементирам - всичоко и навсякъде, за каквито и да е конфигурации трябва да е YAML, но това е друга тема ). 
Това за корпорациите също не го разбирам ( най-малкото си дал примери с IBM и ORACLE, като алтернативни решения ) - имаше алтернативи преди SystemD да се наложи ( Upstart/SystemV ).
Като цяло аз съм точно за налагане на стандарт на абстрацкия върху потребителите ( без значение - обикновен потребител/sysadmin etc. ). Това, че имаш стандарт на имплементация на сървиса - по никакъв начин не ти връзва ръцете за имплементацията на App-a, който ще стартираш през него. Дори напротив, дава ти стандартен и предиктивен начин на работа със ситемата ти.
При SystemV беше тотален shit положението, и сървиси се пишеха, на кой както му е кеф - predictability 0. 
За документацията - до някъде съм съгалсен, че е shit - но в скорошните release, man pages са ОК - поне според мен ( или аз съм привикнал с времето ).
Можеш ли да дадеш някакъв по-конкретен аргумент кое по-точно не е ОК според теб?
Колкото до авторите аз съм върл фен на Lennart Poettering - че маже кода, няма спор, ама идеите му са ОК, а и има кой да му оправя мазаляка ( в повечто случаи ). А и това пак е много-относително, защото примерно в kernel maling list-ите, ако проследиш дискусии - има доста по-големи мазаници, които се merge-ват upstream.
А това ,че има бъгове, които не са оправени много време, си а абсолютно нормална dev процедура. Ако, бъга няма директен security impact и не засяга голяма, част потребители - може да се отложи във времето, ако има лесен workaround - също. Ако за някой е голям проблем в тези случаи - може да си напише patch, или да наеме екип, който да го напише - за пример Facebook правят точно това, точно със SystemD и до колкото се сещам upstream-наха наскоро техни доработки.

В Юникс добрата практика е една програма да прави само едно нещо,но да го прави като хората. SystemDisease е един огромен блоутъер и тумор,който освен да менажира сървисите се меси и на куп други места - виж systemd-logind , systemd-resolved и всичките ред хатски и гномски кочини. Счупи ли се нещо по системд зависва цялата система. SMF на Соларис, понe  няма хардкоднати депендънсита, Даже позволява ако ти е кеф , да си ползваш старите rc скриптове - при системд е просто симлинк към /bin/systemctl  . Когато едно нещо се прави, уж да улесни потребител/админ идиот, от това страда стабилността и сигурността на системата - пример Уиндоус. А Линукс доста сериозно се е запътил по кофти път. Нищо тамън ще се отвори шанс за доброто старо класическо BSD.

Линк към коментара
Сподели в други сайтове

на 4.09.2019 г. в 22:36, petie1 написа:

Нека в тази тема обсъждаме проблема със snap systemd и други подобни неддолюбвани неща за да не се пилее знанието по други теми

Аз така си помислих, че темата е за друго. Според заглавието, би трябвало да е как да си конфигурираш сървър Debian-а, че да не ти го хакнат след 15 мин.

преди 15 часа, ТерминалТора написа:

SystemDisease

:D +1

преди 17 часа, borovaka написа:

При SystemV беше тотален shit положението, и сървиси се пишеха, на кой както му е кеф - predictability 0.

Ако някой беше заменил SystemV навремето, сега дейстително нямаше нямаше да имаме "удоволствието" SystemD. Така че поне по тази точка си много прав.

...........................................

Ето една интересна, свързана новина:

Цитат

Debian May Need To Re-Evaluate Its Interest In "Init System Diversity"

Debian Project Leader Sam Hartman has shared his August 2019 notes where he outlines the frustrations and issues that have come up as a result of init system diversity with some developers still aiming to viably support systemd alternatives within Debian. 

https://www.phoronix.com/scan.php?page=news_item&px=Debian-Init-Diversity-Question

преди 15 часа, ТерминалТора написа:

Когато едно нещо се прави, уж да улесни потребител/админ идиот, от това страда стабилността и сигурността на системата - пример Уиндоус. А Линукс доста сериозно се е запътил по кофти път. Нищо тамън ще се отвори шанс за доброто старо класическо BSD.

И аз оставам с такова впечатление!

Линк към коментара
Сподели в други сайтове

преди 2 часа, Melmak ® написа:
 
Аз така си помислих, че темата е за друго. Според заглавието, би трябвало да е как да си конфигурираш сървър Debian-а, че да не ти го хакнат след 15 мин.

И това може да обсъждаме защо не?

Линк към коментара
Сподели в други сайтове

Нещо интересно по темата за SystemD ( реално няма общо със SystemD, но това си е грешна стратегия от бая време на  Lennart) :

https://streaming.media.ccc.de/asg2019/relive/164

Идеята ми се вижда доста-добра. Проблем има примерно със SSH към машина на която не си логнат локално - след като home partition-a е заключен, реално не можем да направим SSH към дадения User. За това обаче си мисля, че има лесен Workaround, ако има 2 images - единия да е home.username а другия meta.username (който да държи примерно authorized_keys на потребителя ). Така може реално да се напарави SSH към dummy акаунт с рандом UID, който да има право единствено да отключи LUKS-a на съответния User. След това нещата са прости: su - username

Та какво мислите вие за идеята?
 

 

Линк към коментара
Сподели в други сайтове

на 19.09.2019 г. в 22:01, petie1 написа:

И това може да обсъждаме защо не?

Да, принципно ме интересуват и двете.

преди 1 час, borovaka написа:

Та какво мислите вие за идеята?

Че казуса е интересен и пак пипа по чувствителни зони. :)  Навлиза в сферата на automation на заучени действия и по-скоро не би трябвало той да го прави.

на 19.09.2019 г. в 1:56, borovaka написа:

Можеш ли да дадеш някакъв по-конкретен аргумент кое по-точно не е ОК според теб?

Едно от нещата, които много ме съмняват е трябва ли да реализира събития и съобщения в SystemD. Струва ми се че е съществена грешка, защото може да се отделят и проблематиките там са достатъчно обширни и засукани. Демек невъзможно е да се реализират добре от първия път, какво остава ако програмата му прави четири сложни действия - управление на стартирането /състоянията/, сървиси, месинджинг и събития. Даже са много повече, но да не издребнявам излишно.

Линк към коментара
Сподели в други сайтове

преди 39 минути, Melmak ® написа:

Едно от нещата, които много ме съмняват е трябва ли да реализира събития и съобщения в SystemD. Струва ми се че е съществена грешка, защото може да се отделят и проблематиките там са достатъчно обширни и засукани. Демек невъзможно е да се реализират добре от първия път, какво остава ако програмата му прави четири сложни действия - управление на стартирането /състоянията/, сървиси, месинджинг и събития. Даже са много повече, но да не издребнявам излишно.

За SystemD като цяло ли говориш? Или само за Init часста?
Реално SystemD много отдавна не е само Init система

Линк към коментара
Сподели в други сайтове

преди 8 часа, borovaka написа:

Нещо интересно по темата за SystemD ( реално няма общо със SystemD, но това си е грешна стратегия от бая време на  Lennart) :

https://streaming.media.ccc.de/asg2019/relive/164

Идеята ми се вижда доста-добра. Проблем има примерно със SSH към машина на която не си логнат локално - след като home partition-a е заключен, реално не можем да направим SSH към дадения User. За това обаче си мисля, че има лесен Workaround, ако има 2 images - единия да е home.username а другия meta.username (който да държи примерно authorized_keys на потребителя ). Така може реално да се напарави SSH към dummy акаунт с рандом UID, който да има право единствено да отключи LUKS-a на съответния User. След това нещата са прости: su - username

Та какво мислите вие за идеята?
 

 

Хем е добра хем не е като е писал Мелмак

преди 7 часа, Melmak ® написа:

Да, принципно ме интересуват и двете.

Темата е за това така че дерзайте

Линк към коментара
Сподели в други сайтове

преди 21 часа, borovaka написа:

За SystemD като цяло ли говориш?

Да. За systemD като цяло.

преди 21 часа, borovaka написа:

Реално SystemD много отдавна не е само Init система

Хм, знам това. Ама понеже питаш какво поставяме под съмнение...

Линк към коментара
Сподели в други сайтове

Накратко за SystemD:

https://www.opennet.ru/openforum/vsluhforumID3/118577.html#20

Извинявам се, че е на руски език, но ми хареса краткото и точно описание на "проблема SystemD".

Линк към коментара
Сподели в други сайтове

преди 1 час, p4p написа:

Накратко за SystemD:

https://www.opennet.ru/openforum/vsluhforumID3/118577.html#20

Извинявам се, че е на руски език, но ми хареса краткото и точно описание на "проблема SystemD".

Аз изобщо не съм съгласен с твърденията ( като изключим тези за бъговете и code quality :) )
Иначе, много ясно, че като имаш стандартизация - губиш някакво flexibility - реално не го губиш, защото в сървиса можеш да извикакш какъвто искаш код отдолу - той и пича го е писал, че за по нетипични неща му се налага да пилза скрипт/програма. Това обаче за мен си е чист benefit
По-скоро опираме от една страна до манталитет на Developer срещу SysAdmin/User, а от друга до чист hate към проекта и Ленарт.
1) Това, че един проект е OpenSource - не значи - повтарям не значи, че Main development team-a трябва да се съобразява с желания на community-то ( всеки има свободата да го форкне )
2) RedHat ще си правят каквото искат - имат капацитета/парите/development power-a да го правят - това, че стоят зад SystemD и зад Gnome като цяло им дава пълното право да си интегрират едното с другото както искат
3) Ако някой не се кефи на тези технологии - спокойно може да не ги ползва. Въпросът обаче е, че в крайна сметка всички ги adopt-наха, което е показателно
4) Този hate трябва да спре - реално в момента - всичко що е SystemD, идея на Ленард е кофти! Обаче ако някой се загледа в kernel кода, kernel mailing lista - там мазаляка е брутален за доста неща - обаче никой нищо не казва, защото алтернатива няма
5) Според мен - По-добре да имаш продукт с bad code quality, който да е стандартизиран и интегриран - по простата причина, че кода винаги може да се пренапише читаво, ако имаш изграден интерфейс, който се ползва. Другото е много по-сложно да имаш 1000 интерфейса, които всеки ползва както си иска
6) Що се отнася до INIT състема, стартъп скриптовете според мен трябва да са точно сървиси, с ясна дефиниция и без много волности. Ако има някакъв по-сложен сценарий логиката се оставя на програмиста на сътовтения app, който може да я изнесе в някаква bootstrap програма/скрипт, който да се call-не през сървиса - Това е правилния начин. Като администратор, ако отвориш даден service знаеш  какво ще е реално - структура ти е ясна, ако отвориш SystemV скрипт - почваш да се мъчиш да се ориентираш в мазаляка, който някой е решил да сътвори някога.
7) Тази стандартизация ти дава някои интересни свойства - Можеш да sandbox-неш сървиса, можеш да вкараш някакви firewall rules per service и т.н

Някой изобщо замисля ли се, че като прокламира постоянно Ричи-Томпсън философията на Unix от 70-те, е възможно не всичко да apply-ва към днешна дата?
Примерно да изключим SystemD, bash е удобен много, но от силна отживелица, като имплементация. PowerShell като идея е много по-добре измислен - като conversion-a на командите и аргументите към ясно дефинирани обекти, които имат някакъв ясен behavior. На мен bash ми е по-удоен като интерфейс за работа, въпроса е, че това не значи, че е по-добър като замисъл и имплементация (напротив кода е пълен shit ).

Та идеята ми е да не се заклеймява така effort-а на някой, било Ленард/RedHat/Microsoft/Google etc.
Ако някой не го кефи нещо да се спасява - има свободата да си форква, модефицира и да прави каквото иска - въпроса е дали effort-а си струва и дали ще е по-ОК неговата имплементация.

Линк към коментара
Сподели в други сайтове

Бъх, като кликнах на темата и очаквах да видя нещо свързано с добрите практики при работата с линукс дистрибуции и нещо свързано с тяхната сигурност, а то какво се оказа - още една тема " Linux - обща дискусия  4"

Линк към коментара
Сподели в други сайтове

на 16.09.2019 г. в 21:08, ТерминалТора написа:

SystemD е Линукската версия на svchost.exe
 

Когато бях с Уиндоуз, не знам какво ми пречеше този svchost.exe, а и не знаех какво върши - но все се опитвах да го убия през таск менеджера. :D

Сега, като отдавнашен ползвател на Линукс, с твоя помощ разбирам, че подсъзнателната ми агресия към svchost.exe е била права ;)

 

Линк към коментара
Сподели в други сайтове

преди 7 часа, forticius написа:

Когато бях с Уиндоуз, не знам какво ми пречеше този svchost.exe, а и не знаех какво върши - но все се опитвах да го убия през таск менеджера. :D

Не мисля, че имат нещо общо, но пък все пак никой не знае какво прави svchost (без да се види кода), systemd е отворен код, не взема GB-ти и работи.

Линк към коментара
Сподели в други сайтове

  • 3 месеца по-късно...

понеже заглавието на темата е 'добри практики и сигурност в linux', ще си позволя да споделя някои неща, които ми направиха впечатление напоследък. става въпрос за новостите в linux mint 18x и  19x. 

хм, значи за разлика от 17x-версиите в 18x и 19x имаме:

- no-password-long-in   -  логване без акаунт, доколкото разбирам

- инсталиране на soft без да се иска password

- bluebarry под bluetooth автоматично стартиране

'no-password-long-in' тоя feature е просто 'супер яка' нова функционалност, която допринася супер много най-вече за сигурността в linux. тъй ми! някой ако докопа pc с 19-ка, на която е активиран 'no-password-long-in' натиска power-button-а и ... гюдженя в торбата, баджанак! за ко са ти акаунти, пароли, такъи глупости.

'инсталиране на soft без да се иска password' - още по-голям прогрес в същата посока!

'bluebarry под bluetooth автоматично стартиране' - а, и кат са стартира автоматично какво ше напрай? ми ша земи да са вържи към bluebarry-сървъра си по сичките си bluetooth-протоколи. и щот тез, дет се интересуват от сигурност най-обичат колкото се може повече апликации тип server-client кат намерят internet да земат и веднага да estabish-нат връзка с кораба-майка ... пардон сървъра. м - м. а пък туй, дето го разправяха едно верме под път и над път, че bluetooth бил една от най-пробитите технологии вече отдавна не е вярно. намерили са верния път за развитие от mint-а, май.

Линк към коментара
Сподели в други сайтове

Удобството е обратно на сигурността. Така е било и така ще бъде ;) Едното за сметка на другото. Иначе, ако е вярно, леко е стресиращо от страна на Ментата. Но  може да се "целят" към потенциални линукс потребители от Windows и ще е добре дошло малко информацийка от тях и по-малко кликане.

Линк към коментара
Сподели в други сайтове

Минт тотално ми паднаха в очите като дицтрибуция. Логване без парола и некрриптирани пароли съм виждала само в прясно инсталиран   HP-UX.    Имайки предвид че това е юникс на 40 години , е разбираемо. И все пак лесно се сетъпва с няколко команди , ако е и тръстед системата още по-добре.  Но модерна дистрибуция по-подразбиране да разрешава логване без акаунт и парола е недопустимо. За капак че им менте линукс ( отсега така ще го наричам ) натресе това редхатско изчадие и недоразумение системД.

Линк към коментара
Сподели в други сайтове

преди 4 часа, Крематориум написа:

Минт тотално ми паднаха в очите като дицтрибуция. Логване без парола и некрриптирани пароли съм виждала само в прясно инсталиран   HP-UX.    Имайки предвид че това е юникс на 40 години , е разбираемо. И все пак лесно се сетъпва с няколко команди , ако е и тръстед системата още по-добре.  Но модерна дистрибуция по-подразбиране да разрешава логване без акаунт и парола е недопустимо. За капак че им менте линукс ( отсега така ще го наричам ) натресе това редхатско изчадие и недоразумение системД.

offtopic:

Айде пак RH и Lennart са виновни за всичко :D Ама така и до сега не разбрах какво не Ви кефи всички в SystemD ( изключвам имплментацията и някой бъгове )

ontopic:
'no-password-long-in' не е някаква голяма драма - реално, ако си минал след full disk encryption-a, дреме ти дали ще се логнеш, като user - така или иначе можеш да си поиграеш с grub и да вземеш root - иначе идеята не е особено умна де - По тая тема точно Lennart предлагаше SystemD-Homed - което би решило проблема. И да си логнат всичко друго е криптирано - нямаш достъп до данни на други потребители
 

Това за инсталирането на Software без парола - ако е системен е голяма простотия, ако е per user flatpak не виждам нищо лошо - такава му е идеята
Bluetooth-a под кое да е дистро си стартира със сесията - което си е default behavior.

Кое по-точно е много-критично?

п.с. Говорим за дистрибуцията ориентирана за десктоп

Линк към коментара
Сподели в други сайтове

преди 10 часа, borovaka написа:

Кое по-точно е много-критично?

п.с. Говорим за дистрибуцията ориентирана за десктоп

Нищи критично няма, просто изтрещялите параноици се чудят какво да измислят, за да си затруднят живота.

на 20.01.2020 г. в 9:34, kolon написа:

понеже заглавието на темата е 'добри практики и сигурност в linux', ще си позволя да споделя някои неща, които ми направиха впечатление напоследък. става въпрос за новостите в linux mint 18x и  19x. 

хм, значи за разлика от 17x-версиите в 18x и 19x имаме:

- no-password-long-in   -  логване без акаунт, доколкото разбирам

Вижда се колко разбираш - едно голямо НИЩО! Пиши им един мейл на разработчиците на Ментата какви глупаци са и им изнеси една лекция на тема сигурност. Тук у форума напразно си хабиш таланта!

Линк към коментара
Сподели в други сайтове

преди 13 часа, Крематориум написа:

За капак че им менте линукс

Ами те така си я наричат Мента (колко му е една буква):biggrin:

Линк към коментара
Сподели в други сайтове

Добавете отговор

Можете да публикувате отговор сега и да се регистрирате по-късно. Ако имате регистрация, влезте в профила си за да публикувате от него.

Гост
Напишете отговор в тази тема...

×   Вмъкнахте текст, който съдържа форматиране.   Премахни форматирането на текста

  Разрешени са само 75 емотикони.

×   Съдържанието от линка беше вградено автоматично.   Премахни съдържанието и покажи само линк

×   Съдържанието, което сте написали преди беше възстановено..   Изтрий всичко

×   You cannot paste images directly. Upload or insert images from URL.

  • Разглеждащи това в момента   0 потребители

    • Няма регистрирани потребители разглеждащи тази страница.
×
×
  • Добави ново...

Информация

Поставихме бисквитки на устройството ви за най-добро потребителско изживяване. Можете да промените настройките си за бисквитки, или в противен случай приемаме, че сте съгласни с нашите Условия за ползване