Bug 725477
| Summary: | provide an API to scrub | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Dave Allan <dallan> |
| Component: | scrub | Assignee: | Daniel Kopeček <dkopecek> |
| Status: | CLOSED WONTFIX | QA Contact: | BaseOS QE Security Team <qe-baseos-security> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.2 | CC: | dkopecek, sgrubb |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-10-13 07:58:36 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Dave Allan
2011-07-25 15:22:31 UTC
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative. Not sure that writing an API to scrub is the best thing to do security-wise. The more you link into libvirt, the more it can be attacked. Spawning child programs is preferable as any vulnerability cannot be escalated into the main libvirt daemon. Its probably just as good to provide some config string that takes the parameters to be passed to scrub and use them when building the command. If you wanted to capture the output from scrub, you could use something like a safe_popen() which cleans up things before executing: https://fedorahosted.org/audit/browser/trunk/src/auditd-sendmail.c#L72 Then all you need to do is have a sigchld handler. Its also better for selinux policy if you have small confined programs that are called from other programs that are also confined with policy. (In reply to comment #3) > Not sure that writing an API to scrub is the best thing to do security-wise. > The more you link into libvirt, the more it can be attacked. Spawning child > programs is preferable as any vulnerability cannot be escalated into the main > libvirt daemon. Its probably just as good to provide some config string that > takes the parameters to be passed to scrub and use them when building the > command. If you wanted to capture the output from scrub, you could use > something like a safe_popen() which cleans up things before executing: > > https://fedorahosted.org/audit/browser/trunk/src/auditd-sendmail.c#L72 > > Then all you need to do is have a sigchld handler. Its also better for selinux > policy if you have small confined programs that are called from other programs > that are also confined with policy. I should not have limited it to a C API. Basically anything with a defined set of calling conventions would be an improvement over fork/exec/parse the output. I accept your point about not wanting to link, but I disagree that forking a child process and parsing its output is a workable solution. Going that route will simply cause many people to reimplement scrub in their programs and undoubtedly get it wrong. Can you envision a solution in which scrub is started with some programatic way to communicate with it so that clients wishing to call its functionality could pass in a defined set of instructions and receive a defined set of responses? For example, an naive implementation could be JSON over a unix socket. Closing. Reporter is no longer active and I doubt that we'll implement the requested API. |