From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=CrQ8l4MC; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id 542155A0275 for ; Tue, 04 Feb 2025 20:14:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1738696497; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/GTOyE2KqfrHoqzv+DaqS8vSo+qlKoXvI4BKJmbMgmA=; b=CrQ8l4MC6IqlNTGAL5y1oKKVflIp5sTSLxHFTe+wQyEvUlOfS/ceah701W+/2hZ2TBFL3f dF+syoSh4vfNC6fzQdwNEIXoq9PZIThWe07OpKiQrvQlu+pvgolaJS1QSgVXEGKBJ23E6G 12nlklNMJynavf51mazVo2s2PPvHgjA= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-376-MfbBmS5FONulRIGq-zWM9A-1; Tue, 04 Feb 2025 14:14:54 -0500 X-MC-Unique: MfbBmS5FONulRIGq-zWM9A-1 X-Mimecast-MFC-AGG-ID: MfbBmS5FONulRIGq-zWM9A Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-38bf4913669so2824391f8f.2 for ; Tue, 04 Feb 2025 11:14:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738696492; x=1739301292; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=/GTOyE2KqfrHoqzv+DaqS8vSo+qlKoXvI4BKJmbMgmA=; b=mwxQksNxlIvLnlxpYf70oVzanFRDsg0oE/53qj/92YIcSJgWbwIIZQOv07QnG5ec9s 1eQbl6MH+ccoSfKxs88RIqEoo50Vlq04Pz13JGAu0y+WHTPFCA4T7CwuA68fy6gnIgrk X4jV0A1mZWmowuG1sp6qoCjimPYi8iZFw9bRn6crAX2tUDlJd9tZo+/v5TRoZoSq1BUU 06aoYIJpMSbPZHj3oelWZFyV65IiGt/BIBv4eRE5CwE0ELtK8HjjYF8hraDElo9NO1wW jfTLiOtkSQ/yPl58PPtGsYqtGn0WNhBaf/zXhQzlyUbtoMgEwLh5d2Ifnh83vjP/E1Vo IAfQ== X-Forwarded-Encrypted: i=1; AJvYcCU7jtK5SChB2/G+n3zH73D0xLcZTNezcf3tuY3GmOyUDPil+gpTrew7pAlJi88F8YVt+EzDRl2y2FM=@passt.top X-Gm-Message-State: AOJu0YwgGIRfSRyZgqYRv/Rea5MQZziOgg/V92X7WQ8nAZokEhgQWzfa dVMh5QiX2/RRGCiwPAFIFga7j8fdePCei8EXD9sLiVDIs5yLubolN9MLWjoTus2MnrxkfBRJeor vFgp2pz7hFiMDNQAvuBzPYO6yM/Jkkbq7g8147gPFVC5Ytygp4BzW+5PI+2G0BPF/O1jaQ1+g3e WscqD2FbXTrJYe+P3uhBoYxCWxf1lGwode X-Gm-Gg: ASbGnctSDiSQOB7LPjlIGOzE8wvHwXWJ1nGJ3ZwqiCguixahEUWvfwljZtaANaLkpEZ +EorsmnstAHeG87WZN82zWDxSssuBNwT033fb4rbfCR8EAHWpOPuciomTXRQhtD4vW6viW2OSzB i1DxS8DGtpeDUndXnWasGm/vIjsplEp0wNyk5OdCSilv9Ki6t1NPsXRtyeKYdbNVHLePdLo5TxC M6GpugssaTPLrT+vFoSmw/Iy/wDVUybmSDlnK+JM45wjfyqdVz+0FIIUK95QCMZ+wuB6liNEvdg wy9VsZOra8I+lbm+3uUEZz7kiLQVUqChAw== X-Received: by 2002:a05:6000:18a2:b0:38d:b2e4:6d98 with SMTP id ffacd0b85a97d-38db2e47025mr427137f8f.42.1738696492046; Tue, 04 Feb 2025 11:14:52 -0800 (PST) X-Google-Smtp-Source: AGHT+IGAP485QiSMo0Vqd55HU3T4R3dlJ2ZRQErzCjaE/dx2UVwDjaltzaJ16S/yjqOIXMPTK9FvkQ== X-Received: by 2002:a05:6000:18a2:b0:38d:b2e4:6d98 with SMTP id ffacd0b85a97d-38db2e47025mr427116f8f.42.1738696491541; Tue, 04 Feb 2025 11:14:51 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38c5c1cfa3dsm16890537f8f.93.2025.02.04.11.14.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Feb 2025 11:14:50 -0800 (PST) Date: Tue, 4 Feb 2025 20:14:48 +0100 From: Stefano Brivio To: Andrea Bolognani Subject: Re: Apparmor (and other) Issues Message-ID: <20250204201448.0bf3f7a3@elisabeth> In-Reply-To: References: <3mWvqHbG0sGUhoq9ersir5eXDcFpZkAm8BGfuhs3YOBV36rlbJ82aj27diLMkSjg8YQnrQajsHKkcVh3kXG9gc-o2HZF2rQXo9DnqkqbwNQ=@protonmail.com> <20250131212024.34733b6d@elisabeth> <20250203093531.6a71cc81@elisabeth> <0gHPSAbajW7n2zyIE-8k2vez7nkpAHQOnP4p6yfc6i5v948AExss0zBAYKF-92Yqf90DhAg3Xx9u19aw4TtSQLnpNgvCEa--wkPTL0PDdnM=@protonmail.com> <20250204095000.4ca5c43a@elisabeth> <20250204111724.48b73b37@elisabeth> <20250204172242.76889328@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.41; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: kMJW9jHa3TyeizmJm-N37cZifUh3Z6RoggRMfiIv2ss_1738696493 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: E64ABO27YVEU6AUTNV6HDSH3RNBZEO3O X-Message-ID-Hash: E64ABO27YVEU6AUTNV6HDSH3RNBZEO3O X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Prafulla Giri , "passt-dev@passt.top" X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Tue, 4 Feb 2025 18:46:37 +0000 Andrea Bolognani wrote: > On Tue, Feb 04, 2025 at 05:22:42PM +0100, Stefano Brivio wrote: > > On Tue, 4 Feb 2025 15:50:43 +0000 Andrea Bolognani wrote: > > > The additional profiles (libvirt-1cdfdfd3-a020-45d9-8f88-8e0ce31745c4 > > > and its passt subprofile) are generated dynamically when the VM is > > > started and the QEMU process gets the correct one assigned to it. So > > > far so good. > > > > Why do we need additional profiles, I wonder? Are we trying to > > replicate the MCS (Multi-Category Security) stuff from SELinux? > > I'm not well-versed enough in SELinux to be able to answer the latter > question, but I can answer the former. The per-VM profile is needed > to ensure that each VM is only granted access to its own resources. > > $ sudo tail -4 > /etc/apparmor.d/libvirt/libvirt-1cdfdfd3-a020-45d9-8f88-8e0ce31745c4 > profile libvirt-1cdfdfd3-a020-45d9-8f88-8e0ce31745c4 > flags=(attach_disconnected) { > #include > #include if exists > > } > > $ sudo cat /etc/apparmor.d/libvirt/libvirt-1cdfdfd3-a020-45d9-8f88-8e0ce31745c4.files > "/var/log/libvirt/**/alpine.log" w, > "/var/lib/libvirt/qemu/domain-alpine/monitor.sock" rw, > "/var/lib/libvirt/qemu/domain-1-alpine/*" rw, > "/run/libvirt/**/alpine.pid" rwk, > "/run/libvirt/**/*.tunnelmigrate.dest.alpine" rw, > "/var/lib/libvirt/images/alpine.qcow2" rwk, > "/var/lib/libvirt/qemu/domain-1-alpine/{,**}" rwk, > "/run/libvirt/qemu/channel/1-alpine/{,**}" rwk, > "/var/lib/libvirt/qemu/domain-1-alpine/master-key.aes" rwk, > "/dev/userfaultfd" rwk, > > The stuff in the libvirt-qemu abstraction is generic, all VMs get > access to it. The stuff in .files is all specific to the VM. Ah, thanks, it never occurred to me to look into that. So, yes, essentially the same thing as it's done with MCS and SELinux. > > > Do you have any ideas? > > > > Probably you should ask somebody more familiar (openSUSE/Ubuntu > > maintainers of libvirt, or the authors of the virt-aa-helper thing?), > > but a couple of quick ideas: > > > > 1. user-specific subprofiles could be added at adduser time (is there a > > hook?) and libvirtd could use aa_change_hat(2) to select the > > appropriate one based on UID > > > > 2. (most reasonable I think) don't use per-VM profiles for the rootless > > case. Define a single "libvirt-user" (or "libvirt-session") profile > > and use that. We could copy it from the existing ones I suppose. > > Sounds to me like this would require granting the QEMU process access > to roughly the entire filesystem? The disk image could live anywhere > after all, and if we can't dynamically add a rule for the exact path > the only way out is a free-for-all approach. Right. That's what we did for libguestfs as well, the image can be *almost* anywhere. But it's not free-for-all: you're just granting *limited* filesystem access (not to sysfs, not to /etc, and so on). And I had to build a *very* loose profile for libguestfs because that applies to root as well, but for rootless libvirtd, it might even make sense to restrict access to just @{HOME}/** and /tmp/** (that's what I did for stand-alone passt, for example). > > I think that MCS-equivalent functionality is anyway much less critical > > if guests are started as unprivileged users because you have a strong > > separation given by the fact that guests are started as different users. > > > > If all the guests are started as root, and multiple users have access > > to that facility, user separation is much more seriously endangered, > > hence a stronger need for per-VM profiles. > > Ideally you'd still want to isolate unprivileged VMs from each other. > If you don't, what's the point of using AppArmor in the first place? Well, you are still restricting them significantly, for example they can't run random binaries, send arbitrary signals to other processes or to each other, and access a ton of places on the filesystem. Perhaps that's even more important than curbing filesystem access, because that should already be significantly restricted. > > I can try to work on this but I'm really a bit too busy right now. If > > you can, great, otherwise, let me know. On the other hand this feels > > pretty urgent. :( > > I'm afraid I have neither the time nor the expertise to work on this > myself. I'll try to submit a pull request at least for Debian in a couple of days. I guess it would be nice if you could ask other maintainers meanwhile. -- Stefano