On 05/09/2013 02:20 PM, William Roberts wrote:
Yeah I thought about doing exactly what your patch does, but didn't like
hard-coding "logwrapper", as anyone forking/execing across another thing
similar to logwrapper will have the
same issue. I liked it to be consistent.
Pros of your approach:
- No need for logwrapper-specific knowledge in init.
Cons of your approach:
- Developer burden (must remember to specify seclabel in init.rc when
inserting logwrapper before any service, even if only doing it
temporarily for development/debugging),
- Policy-specific knowledge in init.rc (security context of service),
- Policy burden (have to allow entrypoint to logwrapper for all service
domains).
And the pros and cons of my approach are essentially the reverse.
If you want absolute consistency, then we ought to require specifying
seclabel for all services in the init.rc. Then there is never any
ambiguity about whether it is needed or not. But that seems onerous and
will encode a lot of policy info in the init.rc.
--
This message was distributed to subscribers of the seandroid-list mailing list.
If you no longer wish to subscribe, send mail to majord...@tycho.nsa.gov with
the words "unsubscribe seandroid-list" without quotes as the message.
