( nice | 2011. 11. 16., sze – 23:52 )

Bocs, hogy eddig nem tudtam válaszolni, nemrég műtöttek, nagy a család, meg minden ilyesmi. Szóval:

1. Ja, igen, slashbeast közben már felvilágosított, hogy ez a dolog a vanilla kernel szempontjából nem bug, hanem feature, de megnehezíti a grsecurity életét. Nem tudod, hogy van-e végeleges megoldás (nem workaround) rá?

2. Na, közben rájöttem, és megbeszéltem spenderrel, hogy a jogosultságok tényleg inode-onként vannak tárolva, az öröklésük viszont a vfsmount/dentry fán történik. Ez leginkább a Windows/NTFS biztonsági modelljére emlékeztet engem, bár spender egy kicsit ahhoz képest kicsit path-based irányba tolta el, mert ha pl. letörlünk egy fájlt, majd egy másikat a helyére mozgatunk, akkor az átmozgatott fájl nem hozza magával a jogosultságait, hanem megkapja a letörölt fájlét simán a név miatt. Még akkor is, ha mindkét fájl közvetlenül fel volt címkézve a policy-ben. Hát, nekem nem annyira szimpatikus ez a megoldás. Ráadásul már megint találtam egy - szerintem óriási biztonsági - hibát, miközben ezeket a dolgokat vizsgálgattam. Spender már javítja, azt mondta, holnap kész lesz. Most találtam egy másik bugot is, ezt levélben küldtem el neki, de attól tartok, azt fogja mondani rá, hogy ez feature, ha pedig így van, akkor szerintem ez egy nem igazán jó feature.

3. Ezt nem mint bugot említettem meg. Könnyű ilyet konstruálni, de ez szerintem is egy feature. Pl.:

/test1 r
/test2 rw

echo lajos > /test1/majom
ln /test1/majom /test2/majom

És a /test1/majom csak olvasható lesz, a /test2/majom pedig írható is, pedig ugyanaz a fájl.