[pve-devel] [PATCH manager 0/2] fix small glitch in OSD destruction due to tainting

[pve-devel] [PATCH manager 0/2] fix small glitch in OSD destruction due to tainting

[Stoiko Ivanov]

Saw the forum thread's subject [0]  and was reminded of the issue with the LIO
target provider recently [1].

Depending on feedback I might slowly be inclined to blindly untaint in
run_command again?


[0] https://forum.proxmox.com/threads/insecure-dependency-in-exec-during-osd-destroy.79574/
[1] https://lists.proxmox.com/pipermail/pve-devel/2020-October/045524.html

Stoiko Ivanov (2):
  api2: osd destroy: fix error function
  api2: osd destroy: untaint device before pvremove

 PVE/API2/Ceph/OSD.pm | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

-- 
2.20.1

[pve-devel] [PATCH manager 1/2] api2: osd destroy: fix error function

[Stoiko Ivanov]

Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
---
 PVE/API2/Ceph/OSD.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/PVE/API2/Ceph/OSD.pm b/PVE/API2/Ceph/OSD.pm
index f1f39bf9..685b68bc 100644
--- a/PVE/API2/Ceph/OSD.pm
+++ b/PVE/API2/Ceph/OSD.pm
@@ -575,7 +575,7 @@ __PACKAGE__->register_method ({
 		    # try to remove pvs, but do not fail if it does not work
 		    for my $osd_part (@{$osd_list->{$osdid}}) {
 			for my $dev (@{$osd_part->{devices}}) {
-			    eval { run_command(['/sbin/pvremove', $dev], errfunc => {}) };
+			    eval { run_command(['/sbin/pvremove', $dev], errfunc => sub {}) };
 			    warn $@ if $@;
 			}
 		    }
-- 
2.20.1

[pve-devel] [PATCH manager 2/2] api2: osd destroy: untaint device before pvremove

[Stoiko Ivanov]

We get the device list from ceph-volume lvm list, and decode the json
output, which at that point is tainted (perlsec (1)).
Untaint it here before calling, because it is currently the only
call-site using the information in a problematic way (run_command).
(the only other call-site being in pve5to6)

Alternatively we could untaint while reading the information, but then
should only return a small subset of the ceph-volume output.

The issue is most likely due to
cb9db10c1a9855cf40ff13e81f9dd97d6a9b2698 in pve-common ('run_command:
improve performance for logging and long lines'),

Tested on a virtual testsetup by creating OSDs with second DB disk,
and destroying it via GUI (did not manage to get the error without the
DB disk)

Reported via our community forum:
https://forum.proxmox.com/threads/insecure-dependency-in-exec-during-osd-destroy.79574/

Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
---
 PVE/API2/Ceph/OSD.pm | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/PVE/API2/Ceph/OSD.pm b/PVE/API2/Ceph/OSD.pm
index 685b68bc..b81a8054 100644
--- a/PVE/API2/Ceph/OSD.pm
+++ b/PVE/API2/Ceph/OSD.pm
@@ -575,6 +575,8 @@ __PACKAGE__->register_method ({
 		    # try to remove pvs, but do not fail if it does not work
 		    for my $osd_part (@{$osd_list->{$osdid}}) {
 			for my $dev (@{$osd_part->{devices}}) {
+			    ($dev) = ($dev =~ m|^(/dev/[-_.a-zA-Z0-9\/]+)$|); #untaint
+
 			    eval { run_command(['/sbin/pvremove', $dev], errfunc => sub {}) };
 			    warn $@ if $@;
 			}
-- 
2.20.1

[pve-devel] applied: [PATCH manager 0/2] fix small glitch in OSD destruction due to tainting

[Thomas Lamprecht]

On 24.11.20 19:55, Stoiko Ivanov wrote:
> Saw the forum thread's subject [0]  and was reminded of the issue with the LIO
> target provider recently [1].
> 
> Depending on feedback I might slowly be inclined to blindly untaint in
> run_command again?
> 

now that we cacthed most stuff already? ^^ If we can do so efficiently it can be OK
for me.

> 
> [0] https://forum.proxmox.com/threads/insecure-dependency-in-exec-during-osd-destroy.79574/
> [1] https://lists.proxmox.com/pipermail/pve-devel/2020-October/045524.html
> 
> Stoiko Ivanov (2):
>   api2: osd destroy: fix error function
>   api2: osd destroy: untaint device before pvremove
> 
>  PVE/API2/Ceph/OSD.pm | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 



applied, thanks!