grsecurity forums

what about replacing the acl code with POSIX ACLs [1] and file system capabilities patches [2] ?
the append only flag is default under linux and the hide flag is in my opinion a security by obscurity trick..
filesystem based acls are also rapidly than configuration-file (/etc) ones.

another probably good thing could be the addition of some priviledged UIDs:

a system administrator uid, for daily use, without CAP_SYS_MODULE, CAP_BOOT, CAP_SETPCAP, CAP_LINUX_IMMUTABLE, CAP_SYS_RAWIO, CAP_SYS_PTRACE and so on ..

a network service uid for running network daemons with CAP_NET_RAW, CAP_NET_BROADCAST, CAP_NET_BIND_SERVICE

after an initial configuration with uid 0 we can use the new system administrator uid and work for lowering the priviledges to make our system immune to break-ins possible damages.

excuse me for the sometimes-unclear english

our soon-to-be-developed uid/gid acls will allow us to to the things you were talking about. As for the posix acl subject...they've got their own framework, and i don't think it's suitable for what we want to do with the project. Those things deal only with file acls and not process acls. Also there's a vulnerability in the posix acl implementation that I haven't discussed at length, yet.

POSIX ACLS lack the integration with our process acls.
Also, there are a number of complications with your implementation. If we had a specified 'non-root but admin'
uid, we wuld still have a uid with full privileges, even
if it was harder to get to. It would also require
massive rewrites of both user and kernel space applications,
since maany programs rely on uid 0 to check for admin
status.