<snip>
> >
> > If I understand correctly, the goal here is to avoid the lookup from
> > pid to context. If we somehow Had the context or a token to a context
> > during the ipc transaction to userspace, we could just use that In
> > computing the access decision. If that is correct, then since we have
> > PID, why not just extend the SE Linux compute av decision interface to
> > support
> passing of PID and then it can do the lookup in the Kernel?
>
> That's no less racy than getpidcon().
>
I got a bounce from when I sent this from gmail, resending.
True, but in this case the binder transaction would be dead...
Why not just pass ctx? It's less than ideal, but it might be good enough for
now until contexts get unwieldy big.
grep -rn '^type ' * | grep domain | cut -d' ' -f 2-2 | sed s/','//g | awk ' {
thislen=length($0); printf("%-5s %dn", NR, thislen); totlen+=thislen}
END { printf("average: %dn", totlen/NR); } '
The avg type length for domain types in external/sepolicy is 7. Add the full
ctx:
u:r:xxxxxxx:s0(cat)
1. We're looking at like 18 or so bytes, how do we know this won't be "fast
enough"?
2. What's the current perf numbers, and what's agreed upon on what you need to
hit to be fast enough?
3. I'm assuming the use case is in service manager, but would a userspace cache
of AVD's help? Then you can (possibly) avoid both kernel trips, and you can
invalidate the cache on policy reload and on PID deaths? In the case of service
manager would it always be a miss based on usage pattern? I'm assuming things
would say hey resolve this once, and be done. However, you could only do the
ctx lookup and do the avd based on the policy in user space, thus avoiding 1 of
two trips.
--
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
