Régebben sok problémát okozott egy-egy alkalmazásnál, hogy - tervezési hibából vagy egyéb okokból kifolyólag - csak teljes rendszergazdai jogosultsággal voltak képesek megfelelően futni. Ez a Windows Vista-ban gondot jelenthet, mivel mint minden más alkalmazás, ezek a programok is
csökkentett hatókörrel kell hogy beérjék. A megoldás megint csak a virtuális homokozó. Az olyan programok esetén, melyek a rendszerleíró-adatbázis vagy a fájlrendszer védett helyeire szeretnének írni, az UAC virtualizálja nekik a helyet, vagyis egy könyvtár vagy registry-ág pontos másával
"elhiteti" az alkalmazásokkal, hogy tulajdonképpen a megfelelő helyre írnak, holott természetesen
csak a felhasználó profilkönyvtárában létrehozott mappa- és registry-másolatokban
tevékenykednek. Ezzel a módszerrel megakadályozhatjuk, hogy a régi alkalmazások
teleszemeteljék a rendszermappákat és a registry-adatbázist, valamint elejét vehetjük egy véletlen
(vagy rosszindulatú) módosítás okozta rendszerösszeomlásnak.
A következő címkéjű bejegyzések mutatása: registry. Összes bejegyzés megjelenítése
A következő címkéjű bejegyzések mutatása: registry. Összes bejegyzés megjelenítése
2018. május 28., hétfő
2015. július 20., hétfő
user account control - 5.rész
A User Account Control egy másik feladata a szoftverkörnyezet virtualizálása az olyan
alkalmazások számára, melyek nem többfelhasználós rendszerekre lettek készítve, vagy nem
kezelik jól a jogosultságokat. Meglehetősen sok olyan program létezik, mely vagy nem veszi
figyelembe, hogy többfelhasználós környezetben működik, vagy egyszerűen nem is hajlandó futni,
csak és kizárólag rendszergazdai jogosultságokkal. Az UAC ezért detektálja az alkalmazás
fájlrendszerbe és a registry-be való írási kéréseit, és ennek megfelelően - minden felhasználói
fiókban egyéni - virtuális környezetet hoz létre a programnak. A rendszergazda jogosultságot
megkövetelő programok így tulajdonképpen "azt hiszik", hogy tudnak írni a \Windows, vagy a
\Program Files mappákba, esetleg a rendszerleíró-adatbázis kritikus részeibe is, ám valójában egy, a
számukra létrehozott virtuális valóságban működnek - immáron gond nélkül.
2013. április 13., szombat
az adminisztrátori parancssor beszínezése - 1.rész
Ha egyszerre több parancssoros ablakban is dolgozunk - már csak a véletlen módosítások elkerülése
érdekében is - jól jöhet, ha látjuk melyikben rendelkezünk adminisztrátori jogosultságokkal.
Ahhoz, hogy meghatározzuk a parancssorok hozzáférési szintjét, egy jogosultság-ellenőrző
műveletet kell végrehajtanunk a parancssor indításakor, majd az eredménytől függően más-más
színűre - példánkban pirosra - állítani az ablakot. Ehhez egy registry-beállítást fogunk használni,
mellyel minden egyes parancssor (cmd.exe) indításakor lehetőségünk van egy előre megadott
utasítás végrehajtására.
- Nyissunk egy Jegyzettömböt, majd másoljuk be a következőket:
@echo off
echo. > %systemroot%\admincmd.txt
:start
if exist %systemroot%\admincmd.txt goto admin
goto end
:admin
color 4f
del /q %systemroot%\admincmd.txt
:end
- Mentsük el a fájlt admincmd.cmd néven, majd helyezzük el egy általunk elérhető, tetszőleges könyvtárba. • - Nyissuk meg a rendszerleíróadatbázis-szerkesztőt (regedit.exe), majd navigáljunk az alábbi kulcshoz:
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor"
- Nyissunk egy Jegyzettömböt, majd másoljuk be a következőket:
@echo off
echo. > %systemroot%\admincmd.txt
:start
if exist %systemroot%\admincmd.txt goto admin
goto end
:admin
color 4f
del /q %systemroot%\admincmd.txt
:end
- Mentsük el a fájlt admincmd.cmd néven, majd helyezzük el egy általunk elérhető, tetszőleges könyvtárba. • - Nyissuk meg a rendszerleíróadatbázis-szerkesztőt (regedit.exe), majd navigáljunk az alábbi kulcshoz:
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor"
2012. augusztus 25., szombat
a vista igazi újdonságai - 17.rész
USER ACCOUNT CONTROL (UAC) MÁSODIK RÉSZ
Az UAC másik fontos összetevője a fájlrendszer és a Registry bizonyos részeinek virtualizációja. Ha egy rendszergazdai jogosultságok nélkül futó alkalmazás próbálja meg a rendszer bizonyos védett könyvtárait (Windows, Program Files stb.), illetve a Registry érzékeny részeit módosítani, akkor az UAC egyszerűen átveri a próbálkozót. Hibaüzenetek helyett a védett könyvtár helyett a felhasználói profil egy eldugott részében kap a program egy másolatot az általa módosítandó területről, itt azt csinálhat az adatokkal amit akar, sőt a legközelebbi futásakor is itt találja az általa módosított vagy létrehozott információt. A Registry átírásakor az UAC nem ennyire előzékeny; az egyszer „módosított" adat a módosító program kilépése után elveszik. Az elv tehát nem rossz, az UAC tényleg biztonságosabbá teszi rendszerünket, sajnos a megvalósítása eléggé kezdetleges. Az UAC egyes komponensei ki- és bekapcsolhatók a házirendben, de ezen túl sajnos nem tanítható, azaz nem fogható rá a kivételek kezelésére. Ha a felhasználóknak joguk lenne megadniuk, hogy melyik alkalmazásukat tekintik egyszer és mindenkorra biztonságosnak, automatikusan indíthatónak stb., akkor bizonyára nem kapcsolná ki senki ezt az egyébként igen fontos biztonsági mechanizmust (msconfig.exe -> Tools menü).
Az UAC másik fontos összetevője a fájlrendszer és a Registry bizonyos részeinek virtualizációja. Ha egy rendszergazdai jogosultságok nélkül futó alkalmazás próbálja meg a rendszer bizonyos védett könyvtárait (Windows, Program Files stb.), illetve a Registry érzékeny részeit módosítani, akkor az UAC egyszerűen átveri a próbálkozót. Hibaüzenetek helyett a védett könyvtár helyett a felhasználói profil egy eldugott részében kap a program egy másolatot az általa módosítandó területről, itt azt csinálhat az adatokkal amit akar, sőt a legközelebbi futásakor is itt találja az általa módosított vagy létrehozott információt. A Registry átírásakor az UAC nem ennyire előzékeny; az egyszer „módosított" adat a módosító program kilépése után elveszik. Az elv tehát nem rossz, az UAC tényleg biztonságosabbá teszi rendszerünket, sajnos a megvalósítása eléggé kezdetleges. Az UAC egyes komponensei ki- és bekapcsolhatók a házirendben, de ezen túl sajnos nem tanítható, azaz nem fogható rá a kivételek kezelésére. Ha a felhasználóknak joguk lenne megadniuk, hogy melyik alkalmazásukat tekintik egyszer és mindenkorra biztonságosnak, automatikusan indíthatónak stb., akkor bizonyára nem kapcsolná ki senki ezt az egyébként igen fontos biztonsági mechanizmust (msconfig.exe -> Tools menü).
Feliratkozás:
Bejegyzések (Atom)



