PAX acl options implementation.

[niz]

I just looked that pax acl options code in cvs.
Why to put pax options to subject modes?
I think those should be like capabilities.
Then we could set modes to pax options, like i mode.
Example:

/usr/X11R6/bin/XFree86 {
/dev/mem rwo
+CAP_SYS_RAWIO
-PAX_SEGM_PAGE_EXEC
}

[spender]

I don't agree with that. Implementing it as a capability allows the setting to be modified via userspace without proper authentication. Also, the way it's implemented in the ACL system ensures the proper balance between the binary flags and the ACL flags. eg. they're set up so you can enforce changes from the default flags on a binary.

-Brad

[niz]

I did not mean that you should implement it as capability.. I just meant that PAX_RAND_MMAP is more readable than one character 'R'.
Kernel iplementation is good, but acl syntax could be clearier..

Another thing is CAP_DAC_OVERRIDE,
it could be useful if I could set that to any object like that:

/usr/sbin/apache o {
/var/www r
/var/run/apache.pid w

/home D #<- like this

}

I don't want to give apache DAC_OVERRIDE to everywhere and I want keep permissions 700 at home directories..
Even better if I could someway do that to /home/*/public_html.
Any ideas?
I know that it can't be done in kernel.. because of performance reasons, etc.. but if gradm could be so intelligent that it could handle that kind of things.. Just creating hashes of every file/directory matching that pattern? or something like that..

What you think about those ideas?

[spender]

The part about CAP_DAC_OVERRIDE can be done when I implement nested ACLs. It will still remain a part of the subject ACL, but you will be able to tune it based on the process that executes it.

I suppose I could implement the globbing support, but it wouldn't be dynamic at all in the kernel. All it would do would be applying ACLs to every filename matching that pattern when the ACL system is being enabled.

-Brad

[spender]

I see what you're saying about the pax flags. I agree, it is more clear. The only problem is what to do if someone does something like +PAX_PAGEEXEC, when it's enabled by default. Do we ignore or do we raise an error? I'll think about it and possibly write it up tomorrow.

-Brad

[niz]

The part about CAP_DAC_OVERRIDE can be done when I implement nested ACLs. It will still remain a part of the subject ACL, but you will be able to tune it based on the process that executes it.

That nested acl idea is great and gives lot more flexibility.

I suppose I could implement the globbing support, but it wouldn't be dynamic at all in the kernel. All it would do would be applying ACLs to every filename matching that pattern when the ACL system is being enabled.

That's just what I need and it makes some of my acls much shorter.
There is only few things where I need it and it's not problem that it doesn't refresh when directory content changes(anyway I need to go admin mode and restart acl when I add users).
But if you think it will make too much problems when people don't understand it limitations, then leave that idea.
It's not good if people have false sense of security.

I see what you're saying about the pax flags. I agree, it is more clear. The only problem is what to do if someone does something like +PAX_PAGEEXEC, when it's enabled by default. Do we ignore or do we raise an error? I'll think about it and possibly write it up tomorrow.

I think we need to ignore because it's not good if you need to modify all acls when you change something from kernel.
Maybe gradm could just warn about that. If it's possible.

-Nizery