Re: New proposed system group "scap" and setuid binary "dumpcalls"
Hi Bastian,
Bastian Blank <waldi@debian.org> ezt írta (időpont: 2025. okt. 6., H, 13:16):
>
> On Mon, Oct 06, 2025 at 12:56:41PM +0200, Bálint Réczey wrote:
> > > What is the security model of dumpcalls? Does it pay attention to the
> > > user that invoked it, and only dump calls for processes running with the
> > > privileges of that user (and carefully not dump setuid/setcap/etc
> > > binaries that have elevated privileges the user doesn't have
> > > unrestricted access to)?
> > >
> > > (I looked for this information in the various links provided and didn't
> > > see it stated anywhere obvious; apologies if I've missed it.)
> >
> > AFAIK there is not such protection. Dumpcalls will monitor all
> > supported events on the system by default.
> > One use case for it is remotely triaging system issues where dumpcalls
> > is installed on the remote system and in those cases missing
> > information about setuid/etc. binaries could prevent successful
> > triaging.
>
> Do we have a positive review from the SUSE folks? They require a formal
> review for every new elevated binary.
No AFAIK. It is a good practice, but it may not be required even for
SUSE, since the binary is shipped without being setuid by default.
It can be changed to have the setuid bit in postinst if the
administrator chooses so on the debconf question, following the
example of wireshark and dumpcap.
SUSE's guideline recommends not shipping binaries with the setuid bit set:
https://en.opensuse.org/openSUSE:Package_security_guidelines#Setuid_Binaries
"In general having a setuid bit by default requires good reasons. Most
of the time it's better to ship without setuid bit but including
instructions how to modify /etc/permissions.local instead if needed. "
I think the debconf question is closer to the "instructions", than to
shipping with the setuid bit set.
> But if there is no policy on what processes can be traced, I don't think
> this will be positive.
I agree, dumpcalls exposes a lot of information from the system by
design and it is close to all the information the administrator can
gather. A potential review could check if dumpcalls could be used to
alter the system in addition to monitoring it.
> From my view: it needs to employ the "can ptrace" check for any
> monitored process.
I think that would also be against the monitoring's usefulness. Not
ptrace-able processes can cause issues to be triaged, too.
I see that with the security hat on dumpcall has quite broad access to
the system, but I believe from infrastructure monitoring POV that kind
of access is required.
Cheers,
Balint
>
> Bastian
>
> --
> ... bacteriological warfare ... hard to believe we were once foolish
> enough to play around with that.
> -- McCoy, "The Omega Glory", stardate unknown
Reply to: