Strict ACLs

[Loggy]

Generating ACLs from the learning mode is a very useful - and obvious - way of starting but sometimes allows too much to be seen.

Would it be possible to have "strict" mode for gradm (grsec2) which generates nested subjects. In this way, /etc/passwd for example would only be read by the programs which access it and it could not be read by a simple bash command issued by a user.

There are many other examples of ACLs generated that are rather too lax - a simple learning operation which just ssh's in and logs out will generate a rw for /dev/log which means that the system refuses to start.

[spender]

I would definitely like to do that, believe me. However, it's not really feasible to do full nested subject learning, because of space requirements. I'd have to send the entire chain of filenames to userspace. To allow for this, I'd have to have pre-defined an infinite amount of memory, since I need 4k for each possible filename. The best I could probably do would be to do one level of nested subjects. I could also put the inherit flag on that level of nested subjects if you didn't want the policies to break out of the nested subject on another exec.

I'll have to look into the /dev/log rw thing, because I thought I had cases like that handled. the default policy should never have /dev/log rw, and whatever app that added that rule would get its own subject as a result, so that the default policy would stay least-privilege.

-Brad

[Loggy]

I guess if someone left their learning log open for a week on the whole system this would generate an enormous file which would take a lot of parsing space. In the feet of the operator.

However it may be possible to limit how much memory was used so that modest operations could be parsed fully - say on a single role or better subject - but the greedy would have to cut down their operations somewhat. That would at least enable efficient and conservative ACLs to be built up over time.