Regarding permissions, I think they ideally should not be stored with the files, but in some kind of separate security database. Then, one can easily review and manage them in aggregate. Much safer than littering the file system with them.
I don't think evaluating access control should belong in the kernel. Policy questions like this should be handled by a trusted user space process. When a process tries to access a resource, the kernel should ask the security daemon if it is OK. The security daemon can do whatever you want to answer that, and then just tell the kernel permit or deny. There could be several different security daemons to choose from, depending on needs. A smartphone, or home users desktop, will have very different needs from a server operated by an intelligence agency - rather than one system to fit all needs, multiple systems for different needs may be better.
In principle, what I am suggesting is similar to how I understand RACF (and TopSecret and ACF2) work on IBM mainframes. (OK, not all the associated mainframe-warts, but I think the basic idea is good.) The security software is an add-on to the base OS, the base OS just exposes standard hooks for the security software to integrate with.
To avoid the performance hit of constantly context-switching to the security daemon, the kernel should have some kind of cache. That way, first time process tries to access a resource, kernel asks security daemon for OK. If daemon says yes, then kernel remembers and doesn't need to ask again. If everything is a file descriptor, a good time to do this would be at OPEN time - the kernel asks once when FD is open what access will be permitted for that FD, then remembers that for duration of FD.
I suppose this is the classical capability architecture - if everything is an FD (or in Windows-ese, a "handle"), then we can merge the concepts of FDs with capabilities. And a security daemon is then used at FD/handle creation time to determine for the lifetime of the FD/handle what it can do. It might need to be consulted occasionally once FD is created - e.g. is it OK to pass this FD to another process? Also, if the security permissions are revoked while FD is open, the daemon should be able to ask kernel to forcibly close, or downgrade the rights, of an FD it earlier approved to be opened.