તમારો VPN આદેશ વિશેષાધિકાર વિના ચાલે છે; સેવા નહીં

VPN આદેશ તમારા વપરાશકર્તા તરીકે ચાલે છે, કોઈ પાસવર્ડ દેખાતો નથી, અને ટનલ ઉપર આવે છે. એ ક્રમ વિશેષાધિકાર વિનાની ક્રિયા જેવો લાગે છે, અને સામાન્ય રીતે એવું હોતું નથી. અલગ સેવા નેટવર્કના ફેરફાર કરે છે, અને રસપ્રદ પ્રશ્ન એ છે કે જે કૉલરની તેણે ચકાસણી કરી નથી તેના માટે એ સેવા શું કરશે. પાસવર્ડની વિનંતીઓ ગણવાથી એ સીમા વિશે કંઈ ખબર પડતી નથી.

ઇન્ટરફેસ, કાર્યપદ્ધતિ અને ચકાસણી

ઇન્ટરફેસ વિનંતીઓ સ્વીકારે છે: જોડાઓ, જોડાણ તોડો, પ્રોફાઇલ પસંદ કરો. કાર્યપદ્ધતિ નેટવર્કની ક્રિયાઓ ધરાવે છે: ઇન્ટરફેસ બનાવવા, રૂટ બદલવા, ફિલ્ટર લાગુ કરવા. અધિકૃતિ ચકાસણી નક્કી કરે છે કે આ કૉલર આ ક્રિયા માંગી શકે છે કે નહીં. એ ત્રણ બાઈનરી, સહાયક અને સિસ્ટમ સેવામાં ફેલાયેલા હોઈ શકે છે, અને વપરાશકર્તા ફક્ત પ્રથમ જુએ છે.

ભૂમિકાઓ એક બાઈનરીમાં, બે પ્રક્રિયાઓમાં, અથવા ક્લાયન્ટ અને સિસ્ટમ સેવામાં રહી શકે છે, અને વપરાશકર્તા જે આદેશ જુએ છે તે ભાગ્યે જ જણાવે છે કે કઈ. ટ્રે આઇકન અને સિસ્ટમ ડિમન એક જ એપ્લિકેશન જેવા લાગી શકે છે, જ્યારે તેઓ ખૂબ જ અલગ સત્તા સાથે ચાલે છે. ઇન્સ્ટોલ સમયનો વિશેષાધિકાર અને વિનંતી સમયનો વિશેષાધિકાર પણ અલગ વસ્તુઓ છે. root તરીકે ચાલેલો ઇન્સ્ટોલર પછીની વિનંતીઓ સાંભળતી સેવા છોડી શકે છે, પેકેજ મેનેજર પૂરું થયાના ઘણા સમય પછી પણ. તમે ટાઇપ કરેલો આદેશ નહીં, પણ એ સેવા સત્તા ધરાવે છે.

સોંપણ એ સામાન્ય રચના છે

વિશેષાધિકારવાળું નેટવર્ક કાર્ય સેવાને સોંપવું એ વાજબી રચના છે. તે સામાન્ય એપ્લિકેશનોને વિશેષાધિકાર વિના રાખે છે અને કાળજી માંગતી ક્રિયાઓને કેન્દ્રિત કરે છે. રચના ત્યારે જ ફાયદો આપે છે જ્યારે સેવા પણ ચકાસે કે કોણ માંગે છે અને શેના માટે. એ ચકાસણી વિના તે ફક્ત પહોળું દરવાજું છે.

NetworkManager એ Linux પરનું નક્કર ઉદાહરણ છે. તેની રૂપરેખા માર્ગદર્શિકા સમજાવે છે કે PolicyKit ડિફોલ્ટ સેટઅપમાં બિન-root વિનંતીઓને કેવી રીતે અધિકૃત કરે છે. એ વાસ્તવિક ઉત્પાદનમાં સોંપાયેલ અધિકૃતિ દર્શાવે છે. એ સાબિત કરતું નથી કે દરેક વ્યાપારી ક્લાયન્ટ NetworkManager વાપરે છે, અને કોઈ ચોક્કસ વિક્રેતાનો સોકેટ માર્ગ કે નીતિ વર્ણવતું નથી.

નમૂનો પાછળ નીતિ ધરાવતું સોંપણ છે. ઉદાહરણ એ નમૂનાનું એક અમલીકરણ છે, સાર્વત્રિક નહીં.

સીમા વાંચો, વિનંતી નહીં

સેવા, તેની રૂપરેખાનો માલિક અને આગળનો ભાગ વાપરે છે તે સ્થાનિક ઇન્ટરફેસ શોધો. પછી પૂછો કે કયા વપરાશકર્તા કઈ ક્રિયાઓ માંગી શકે. એક સંગ્રહિત પ્રોફાઇલ ઉપર-નીચે કરવી એ ઓપરેટરે કદી સમીક્ષા ન કરેલી રૂપરેખા લોડ કરવાની સમાન પરવાનગી નથી. ફરક એ આખો સુરક્ષા પ્રશ્ન છે.

સેવા મેનેજર અને ક્લાયન્ટની પોતાની પરવાનગીઓ વિશેની દૃષ્ટિથી શરૂ કરો. નીચેના આદેશો દર્શાવે છે કે ડિમન ચાલી રહ્યું છે કે નહીં, કૉલર તેની પાસે શું માંગી શકે, અને ડિમન તેની રનટાઇમ ડિરેક્ટરી હેઠળ શું આપે છે.

systemctl status NetworkManager
nmcli general permissions
ls -l /run/NetworkManager

એ પણ પૂછો કે ક્રિયા શેને અસર કરે છે. વ્યક્તિગત લાગતું મેનુ આઇટમ આખી મશીન માટે રૂટ અને DNS બદલી શકે છે, એટલે કે તે બીજા વપરાશકર્તાઓના સત્રોમાં ખલેલ પહોંચાડી શકે છે. અસરની ત્રિજ્યા પરવાનગી સાથેની એ જ સમીક્ષામાં આવે છે, અને સામાન્ય રીતે એ જ નક્કી કરે છે કે સેવાને વધુ સાંકડી ભૂમિકા જોઈએ કે નહીં.

સમર્થિત રીતે પરવાનગીઓ સુધારો

સુરક્ષિત નિયંત્રણ સોકેટને બધા માટે લખી શકાય તેવું બનાવવું, અથવા ખાતું પહોળા વહીવટી જૂથમાં ઉમેરવું, પરવાનગીની ભૂલ દૂર કરે છે અને મોટી ભૂલ બનાવે છે. ભૂલ એ જ એક વસ્તુ હતી જે તમને કહેતી હતી કે એ સીમા અસ્તિત્વમાં છે. દસ્તાવેજી સભ્યપદ કે અધિકૃતિ પ્રક્રિયા વાપરો, તેની જરૂરી સત્ર તાજગી સહિત. જૂથ સભ્યપદ ઘણી વાર ફક્ત નવા લોગિન સત્રો પર લાગુ થાય છે, તેથી આગલા સાઇન-ઇન સુધી ફેરફાર કંઈ ન કરતો હોય તેમ લાગે છે.

જો ઉત્પાદન ક્રિયા માટે વધુ સાંકડી ભૂમિકા આપે છે, તો સામાન્ય મંજૂરીને બદલે એ પસંદ કરો. પસંદ કરેલી ભૂમિકા અને તેનો માલિક સેવાના નામ પાસે લખો.

સારો વિભાજન કેવો દેખાય છે

સામાન્ય એપ્લિકેશનો વિશેષાધિકાર વિના રહે છે, સેવા ફક્ત તે જ સેટઅપ કરે છે જેના માટે તે બની છે, અને દરેક કૉલરને કોઈના માલિકીની નીતિ સામે ચકાસવામાં આવે છે. એ બચાવપાત્ર રચના છે. તે ઓડિટપાત્ર પણ છે, કારણ કે નીતિ સાથે નામ જોડાયેલું છે. એથી મોટું કંઈ પણ શાંત પરવાનગી ફેરફારને બદલે લેખિત અપવાદને લાયક છે.

નિષ્ફળતાની રીત એ સેવા છે જે ઇન્ટરફેસ અનુકૂળ હોવાથી કોઈ પણ સ્થાનિક વપરાશકર્તાની કોઈ પણ વિનંતી પૂરી કરે છે. વપરાશકર્તાની બાજુથી તે એકસમાન લાગે છે, અને તે ઘણી મોટી સત્તા ધરાવે છે. એક નકારાયેલી વિનંતી ચકાસો, ફક્ત સફળ એક જ નહીં. નીતિમાંથી આવતો નકાર એ પુરાવો છે કે નીતિ અસ્તિત્વમાં છે.