-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to combine security and usability? #34
Comments
Hey, thanks for opening the issue. I think chowning to the user that ran the program (or root for SUID programs) is a good idea - we'll just have to drop permissions later in corehelper for this to work (corehelper is spawned as root by the kernel to handle the coredump but immediately drops to the coredump user right now but then it can't delete coredumps from other users). Alternatively we could chgrp to the corecollector group. |
I think chgrp'ing to the corecollector group would work, but it should only have write permissions. I can try to make a PR for it, but I haven't looked into D at all. |
Ah right, good thought!
If you do want to look into it, here's roughly what would have to be done:
|
Hi! I was testing out @travankor's PR in void-linux/void-packages#19937 , since this is a type of software I am interested in. So, thanks for writing it!
Per my comment in void-linux/void-packages#19937 (comment) , I think this tool currently doesn't allow for ease of use and security at the same time. Ideally, a user should be able to view their own dumps without extra privileges or at least without needing to call a tool like
sudo
. This can be somewhat achieved by adding said user to thecorecollector
group. Unfortunately, this also means that the user will get access to suid core dumps, which is a security concern. Furthermore, on a multi user system (less of a concern, but still present), being a part of thecorecollector
group means being able to inspect core dumps from all users.I think a proper solution would be
chown
ing suid dumps to root (both user and group), as well aschown
ing user dumps to said user. I am unsure of the implications of this, and I am open to discussion for possible solutions. Furthermore, implementing the behavior described inproc(7)
forfs.suid_dumpable=2
might be the best way of doing so: allow members ofcorecollector
group to remove any core dump, but make core dumps readable only by the user that generated them or by root, when from a suid or sgid binary.This issue is a potential extension of #27 , I believe.
The text was updated successfully, but these errors were encountered: