irc-n mar kb kibeszeltuk, szoval csak roviden:
1. a /proc problema nem a path kezeles miatt volt, hanem mert nehany verzioval ezelott valaki kitalalta, hogy milyen jo dolog lenne, ha /proc alatti file-okhoz dinamikusan allokalt inode-ok tartoznanak, ertve ez alatt azt, hogy egy procfs mount elettartama alatt *nem* stabilak az inode-ok, igy aztan hozzajuk rendelni metainformaciot is eleg nehezkes (nem csak a grsec kuzd meg a procfs-sel, l. SE_SBPROC meg strcmp(sb->s_type->name, "proc")).
2. az inode per-fs egyedi azonosito ill. struktura (es nem globalis), kernelben (futasidoben, memoriaban) mindig egy vfsmount ala tartozik. amiben a grsec elter a tobbi cimkezo rendszertol az az, hogy a cimkek nem kozvetlenul tarolodnak a filerendszerben a file-ok melle, hanem policy betolteskor konstrualja meg oket (igazabol a policy nem csak a letezo file-okhoz tarol metainformaciot, hanem a nem letezokhoz is). tekinthetjuk ugy is, hogy a grsec policy egy nagyon human readable tomoritett formaja annak, amit a tobbiek (sokak szerint nem kis komplexitas aran ;) a filerendszerben kenytelenek tarolni.
3. "Egyébként még tovább növekszik a SELinuxhoz viszonyított különbség az által, hogy a Grsecurity-ben ugyanarra a fájlra különböző jogok vonatkozhatnak, ha más path-on (hard link) keresztül hivatkozunk rá." - ha tudsz ra peldat konstrualni, akkor mehet a bugreport spendernek meg kerhetsz ra CVE-t, en meg vegre root leszek a grsecurity.net-en ;). amire esetleg gondolhattal az az, hogy egy file-ra (eleresi utvonalatol fuggetlenul) kulonbozo jogok vonatkozhatnak kulonbozo subject-ek szamara, de ez mas rendszerekben is igy van.