Uthibitishaji wa PAM hufanya kazi kwa mkono lakini hushindikana kama huduma ya OpenVPN

Uthibitishaji kupitia PAM unaweza kufanikiwa unapowasha mteja kwa mkono na kushindikana kwa AUTH_FAILED mara tu systemd inapoanzisha wasifu huo huo. Neno la siri halibadiliki kati ya uendeshaji huo; kinachobadilika ni seti ya vikwazo kuzunguka mchakato unaouliza PAM swali. PAM hujibu kupitia msaidizi ambaye uwezo wake wa kubadilisha vitambulisho vyake mwenyewe ndiyo hasa kitu ambacho kitengo kilichoimarishwa huondoa. Tafuta msaidizi huyo na mpaka anaouhitaji kabla ya kugusa orodha ya uwezo.

unix_chkpwd ni faili binary inayojibu swali la PAM

Kwa uthibitishaji wa neno la siri la ndani, pam_unix mara chache husoma faili ya hash yenyewe. Huendesha unix_chkpwd, ambayo usambazaji huiweka kama setuid root au setgid shadow ili neno la siri moja liweze kukaguliwa kwa niaba ya mchakato ambao haupaswi kusoma /etc/shadow. Ondoa uwezo wa kupata utambulisho huo, msaidizi hataweza kukamilisha ukaguzi, kwa hiyo moduli hurudisha hitilafu ya kawaida ya uthibitishaji.

Kushindikana basi huonekana kama tatizo la vitambulisho katika kila kumbukumbu ambayo mteja anaweza kuona. Hiyo ni mtego: mteja huripoti kile PAM ilimwambia, na PAM huripoti tu kwamba mrundikano ulisema hapana. Kuendesha msaidizi kwa mkono kama root pia hakuthibitishi chochote, kwa sababu kunatumia njia ya ruhusa ambayo huduma haitumii kamwe. Soma kitengo ambacho systemd iliyopakia kweli, kisha soma kumbukumbu ya mfumo kwa jaribio lililofanywa. Mitazamo hiyo miwili hutenganisha tatizo la sandbox na tatizo la neno la siri lisilo sahihi.

Soma kitengo kabla ya kusoma kumbukumbu ya neno la siri

Kitengo kilichopakiwa kinaweza kuwa na drop-in ambayo hukuiandika, na usanidi unaofanya kazi ni matokeo ya kuunganishwa. Chapisha kitengo jinsi systemd inakiona, pamoja na mipangilio ya sandbox inayoamua kama msaidizi anaweza kujipandisha. Ukaguzi wa kusoma tu unatosha katika hatua hii.

systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p CapabilityBoundingSet -p AmbientCapabilities -p NoNewPrivileges
journalctl -u [email protected] -b

Amri ya kwanza inaonyesha kitengo na drop-in zake zinatoka wapi, jambo lenye maana kwa sababu ubatilishaji ulioongezwa miezi iliyopita huishi muda mrefu kuliko kumbukumbu ya kwa nini upo. Ya pili huchapisha thamani za sandbox ambazo sehemu mbili zinazofuata zinategemea.

Linganisha unachokiona na mwenyeji anayefanya kazi wa usambazaji na toleo sawa. Tofauti katika User, CapabilityBoundingSet au NoNewPrivileges ni kidokezo halisi; tofauti katika maoni ya maelezo siyo. Andika thamani kabla ya kubadilisha chochote, kwa sababu ulinganisho wa baadaye dhidi ya lengo linalosonga hauthibitishi chochote. Ikiwa huduma inaendeshwa kama akaunti isiyo na ruhusa na seti tupu ya mipaka, msaidizi hana karibu chochote cha kufanyia kazi.

Mabadiliko ya vitambulisho, ufikiaji wa faili na sera ni mipaka mitatu

Anza na kile kinachotokea wakati wa exec. Faili binary ya setuid au faili iliyo na file capabilities husababisha mabadiliko ya vitambulisho, kwa hiyo utambulisho unaotokea si mwendelezo wa anayeita. Seti ya mipaka hupunguza kile binary kama hiyo inaweza kupata, na NoNewPrivileges huzuia kabisa upatikanaji wa setuid, setgid na file capabilities. Yoyote kati ya hizo tatu inaweza kusimamisha msaidizi huku kila kazi nyingine ya huduma ikibaki sawa.

Kisha tenganisha upitaji mpana wa hiari na ufikiaji mwembamba wa kusoma. CAP_DAC_OVERRIDE huruka ukaguzi wa hiari karibu kila mahali, wakati CAP_DAC_READ_SEARCH inashughulikia kusoma na kupita kwenye saraka kwa mamlaka yake ya ziada. Ni zana tofauti zenye wigo tofauti, na hakuna hata moja iliyo njia ya kuandika acha PAM isome faili ya shadow.

Mwisho, uliza kama sera ya lazima inaruhusu kitendo hicho hata kidogo. Uwezo wa Linux haupitishi SELinux, na kuwa nao hakuthibitishi chochote kuhusu kanuni ya utekelezaji wa aina. Chukua kukataliwa kwa ufikiaji wa faili na kukataliwa kwa uwezo kama ushahidi tofauti, kwa sababu hutaja marekebisho tofauti na mara nyingi wamiliki tofauti. Soma kila sehemu ya rekodi badala ya neno moja denied. Programu ipi inayotekelezeka ilifanya kitendo, ilikuwa ikifanya kazi katika kikoa kipi, iligusa aina gani ya lengo, darasa gani la kitu lilihusika na ruhusa ipi sera ilikataa - kila moja ya haya hupunguza jibu kwa namna tofauti.

Toa kukataliwa kutoka kwa kumbukumbu ya ukaguzi

Kwenye mwenyeji katika hali ya enforcing, njia ya ukaguzi ndiyo mahali pekee panaporekodi kukataliwa. Uliza kuhusu matukio ya hivi karibuni na uyasome kwa mujibu wa muhuri wa muda wa kuingia kulikoshindikana, si kwa mujibu wa muda ulioanza uchunguzi.

ausearch -m AVC,USER_AVC -ts recent

Matokeo tupu si ushahidi wa kutokuwa na hatia. Inamaanisha ama ukaguzi haukusanyi, au dirisha lako lilikosa jaribio, na uwezekano wote wawili unapaswa kuondolewa kabla ya kuondoa sera.

Mwongozo wa Red Hat wa kutatua matatizo ya SELinux huweka ukaguzi wa lebo na usanidi mbele ya kuzalisha kanuni za kuruhusu, ambayo pia ni mfuatano sahihi kwa tatizo hili. Faili binary ya msaidizi iliyowekwa lebo isiyo sahihi na pengo katika sera huzalisha kukataliwa kufanano lakini huhitaji marekebisho tofauti. Kuzalisha kanuni ya kuruhusu kwa hitilafu ya lebo huficha kasoro na kuiacha sasisho la kifurushi linalofuata kuirejesha. Thibitisha lebo kwenye msaidizi aliyesakinishwa kabla ya kuandika sera yoyote.

Thibitisha mabadiliko kwa kuingia kumojakukubaliwa na kumojakukataliwa

Badilisha tu mpaka uliouonyesha, kisha jaribu matokeo yote mawili. Akaunti inayopaswa kuthibitika lazima ifanikiwe, na akaunti yenye neno la siri lisilo sahihi lazima iendelee kushindikana. Mabadiliko yanayofanya kila jaribio lifanikiwe yameondoa uthibitishaji badala ya kuurekebisha.

Fanya jaribio halisi la kuunganisha na usome kumbukumbu mara moja baadaye. Mstari unaothibitisha marekebisho ni ingizo la pam_unix(openvpn:auth) kwa jaribio hilo: linapaswa kusema uthibitishaji umefanikiwa, na hakuna rekodi ya AVC inayopaswa kubeba sekunde hiyo hiyo.

journalctl -u [email protected] -n 30 --no-pager
ss -tnp | grep openvpn

Tunnel inayofanya kazi pia inahitaji kuunganisha upya, kwa sababu mabadiliko ya sandbox huvunja muunganisho wa pili mara nyingi zaidi kuliko wa kwanza. Angalia soketi iliyoanzishwa baada ya kuunganisha upya na uthibitishe kwamba kitengo kilekile bado kinaihudumia.