Hide Forgot
BZ 725013 requests secure wipe of retired VMs. libvirt can fork and exec scrub, but that is sub-optimal compared to an API with proper error reporting, etc. scrub, as a vetted component with security implications, should provide a C API so that it can be reused by other components. Such an API should provide the full expressiveness of the scrub commandline.
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.