Is any of those time can be run in the capability program?
If so does we need caph_cache_tzdata ?

Up to you: but this can be writen shorten:
caph_rights_limit(signalpipe[1], cap_rights_init(&sigtxpipe_rights, CAP_WRITE));

This is my private preference, so it's up to you what you will do with it:
I just prefer to have a fixed list of capability rights for the descriptors other ways it's getting compacted to say from the code what capabilities they are.

Why don't lmit it in the first if?

We don't need a caph_cache_catpages ?

Should we use casper service here for the syslog?

Nope- those ones are confined to builtins that don't fork

So, the problem is that I don't want to be duplicating the caph_stream_rights() because then that would need to be maintained, but I need them since the invoked program may attempt to caph_limit_stdio().

Will do

This branch doesn't get hit in the caph_enter() path, but both are things we'll need to consider going forward (that I hadn't previously) when we allow inetd.conf specifying that a service should be capsicumized.

I'd consider combining bi_fork and bi_capenter into a bi_flags variable. That'd make it easier to read the table.

Why do we not support cap mode for any of the UDP services? Seems like discard_dg should be trivial.

It reads a bit strangely to check fakeid_fd == -1 after calling caph_limit_stream(). You might consider extending the existing if-statement instead, i.e.

if (fakeid_fd == -1 ||
    caph_limit_stream(...) == -1 ||
    fstat(...) == -1 ||
    ...

This could be collapsed into the following if-statement (for now). You are duplicating the sep->se_bi != NULL test.

Why caph_limit_stream()? fakeid_fd isn't wrapped with a FILE. I'm not sure why it's useful to limit rights here at all (fakeid_fd doesn't get inherited by children?), but cap_rights_limit(fakeid_fd, CAP_READ) would make more sense.

ctrl_ioctls seems like a slightly clearer name.

Can this just be calloc()?

I don't quite understand this reasoning.

Are we limiting rights on the same socket each time the service is invoked?

It's less about it being a UDP service and more about not forking for it -- I generally declined to touch any that we currently don't fork off in the first iteration.

Fair point; dropped entirely

It might have made more sense to chop off the first sentence entirely, maybe something more like:

Service sockets are created via accept(2), thus inheriting the rights of the control
socket.  Therefore, control caps must be a superset of those needed by the services.
Apply rights here for both service sockets and control socket to make it easier to
audit that this is happening.

Reading it again, yeah... this would seem to boil down to setup_ctrl_caps(sep->se_fd, sep);

Ok, that seems fine to me.

Not the end of the world I guess, but worth an XXX comment or so if you prefer to keep it as is for now.