adlr: who would be the right owner for this? Could you provide more details on the vulnerability? This needs to be triaged as a security bug. Thanks!

Assigning to adlr@ to triage. Please adjust the impact/severity labels as needed.

Taking the initiative to lower the priority and target. CUPS hasn't launched any externally visible features, and the $subject security measures are more of a "nice to have" than a requirement.

See also issue 620192, which is more likely to be implemented in the short term.

Fine with me, assuming the commitment to implement this before the external launch still stands.

Started looking at what needs to happen here.  Some notes:

cups appears to have internal support for some sandboxing of filters, through use of the cups-exec spawner.  This spawner doesn't seem to have documentation, or, if it does, I haven't been able to find it.  It appears to have been added for/by Apple for MacOS back in 2011. 

From the source for the program, it looks like it can do uid/gid/nice level, and then has extra hooks for MacOS-specific (and now deprecated) sandbox functionality.  So I don't think we can use this.

If we want to use a different user from cupsd, we'll have to figure out how to get CAP_SETUID/CAP_SETGID plumbed in a workable way, or decide if a user namespace based solution is sufficient instead.

It looks like we also need a hook in scheduler/process.c to allow for invoking subprocesses with minijail, and some mechanism for passing through policy (assuming that policies need to be per-filter).  This would parallel the stuff that's already in there to support cups-exec.

At some point, vapier@ suggested libseccomp. Might look into that. Doing set{u,g}id might be a bonus.

Friendly ping from the security sheriff. Any updates here?

Also, does this need to be tracked as a security vulnerability? It sounds like maybe more of a security-related feature request than a vuln?

This is on my plate for this week.  The fact that cupsd itself is minijailed is making this a little more complicated than it would otherwise be.  We want to have this in when cups becomes generally available.

Not a security bug indeed, but a feature. Relabeling accordingly.

 Issue 685813  has been merged into this issue.

moving feedback from the CL (https://chromium-review.googlesource.com/433237) here for better tracking

namespaces/seccomp filters are preserved across forks/execs.  that means the filters active for cupsd are also already active for the filters, and that they operate in the same namespaces as cupsd (and not in the original/parent ones).

trying to do more here gets tricky: if we want to have filters run in diff namespaces/seccomp via minijail, we have to open up more syscalls in cupsd to support it (like unshare & mount & umount).  doing a diff on the filters doesn't seem like it improves overall security.

so i think it's better that we don't try to do that.  if we wanted to really lock them down, we'd write a new small daemon that exists just to spawn all the cups programs through minijail.  that'd mean changing cupsd to talk to that program whenever it needed a filter launched.

in the mean time, not landing that CL sounds best.

Thanks for the feedback. Once we had an idea of launching those filters using the existing process manager (like upstart) instead of writing a new daemon. What do you think about using this approach? Or does there really need to be a new daemon?

using socket activation you mean ?  i think that'd be fine too.

mmm, this isn't something we can ignore

progress has been made, but i don't know the current status.  maybe Sean can comment.