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=CyGg3uRN; 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 742ED5A0275 for ; Tue, 04 Feb 2025 19:46:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1738694800; 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: in-reply-to:in-reply-to:references:references; bh=/EQh12SskW2PUltYnfW2tIHBYSD7eEk4F3y3dDjsKPQ=; b=CyGg3uRN9WYZALGouhVJ8n2AHwLkT6686tV/uw8BiWICiYSqgKbSs8ybqRylEi+EQqfE+M N0/XHJyqaRMyL628IBxAfv5FNI3qe2NUj4zWKspmeC39mktnYfzaWZNkiY3Sw4tHD3mDuv UQETImgty23cAeudeqUwkeRkW4oYO40= Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-38-pr8zoeSjPP-ePpLUcEY1Tw-1; Tue, 04 Feb 2025 13:46:39 -0500 X-MC-Unique: pr8zoeSjPP-ePpLUcEY1Tw-1 X-Mimecast-MFC-AGG-ID: pr8zoeSjPP-ePpLUcEY1Tw Received: by mail-qt1-f197.google.com with SMTP id d75a77b69052e-467a0a6c846so125432061cf.1 for ; Tue, 04 Feb 2025 10:46:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738694798; x=1739299598; h=cc:to:subject:message-id:date:in-reply-to:mime-version:references :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=/EQh12SskW2PUltYnfW2tIHBYSD7eEk4F3y3dDjsKPQ=; b=Bp41N+t+EztNFDC4UMY0bxz72ITtU1lBqYBlH1lyk9T51/V/pSTwWVmBiR67acyZ3/ p/qT4apjJMlTSeo4p38PrW36I8X1jzf4E3rPiHgUYFlTtsCTzihaGBvWntLaRLi60dlX od7ATfDeAx4XAdh08FJZBgNqMbUjwn7jjT+482nNbE4wA38IGzwqlM/nV3SO5bmf66nE U+B3rephsnldyu6sk7pYK8r08H6OXv+ZWU+VO/8pijljnq7TaWhJkUwYOMGo6PrsBIcs /tor7Daup5B+2bcsAUA2/xJ1y/MI07N/Ho0xKU3bP095Er3vJ+aMNKL/RLAK424bma2x bghg== X-Forwarded-Encrypted: i=1; AJvYcCUxoNDns+mKtK2t9q/Fp5TAswJ5NiQsxR986ta7U3lWC32UGzBilFzLqQJLW1o2ryENnfDdGJQlu40=@passt.top X-Gm-Message-State: AOJu0YzSk9yPfBLjnRXra9rqGF/eT65/RPy3evXwOypKHlUrpNpV+pC4 vmO6nxvVTW2loDdmPW+sUIkLbIqvAaj5by0R94Mp7J1PAV6Of37JLxLigoSjX7pxhBFo90AoCQ9 17W2UTUiwbN0JwW+T45g4iHmazi6DwP1ftLSZTi2hA76g0chyLm38BW4LDl426K/mukOYbrd/Of P6zpEE0TFUM0bovOjx9lMpuEZW X-Gm-Gg: ASbGncvuHTXV7xdyi3FANO1XQAG4gUZfSaom7AqRuTMDvIe07F2dk9wqvzh3yQtSZgK tD1wYGVR1ptPfXl39SGLpM8h+KDdgJYf+swLPbHGX/KqB8lEjZdZ947sXIrpe X-Received: by 2002:ac8:57cf:0:b0:460:8e3b:6790 with SMTP id d75a77b69052e-46fd0bccee1mr343089621cf.48.1738694798637; Tue, 04 Feb 2025 10:46:38 -0800 (PST) X-Google-Smtp-Source: AGHT+IHW0ZY7qSLJ1oDv5lt5jmVYbYxlGa03c55aKq41VSg1UNXRHbyPKNEA9JPcaP/uYNOPRQW1LuGr3gPbfV/GKUs= X-Received: by 2002:ac8:57cf:0:b0:460:8e3b:6790 with SMTP id d75a77b69052e-46fd0bccee1mr343089421cf.48.1738694798382; Tue, 04 Feb 2025 10:46:38 -0800 (PST) Received: from 744723338238 named unknown by gmailapi.google.com with HTTPREST; Tue, 4 Feb 2025 18:46:37 +0000 Received: from 744723338238 named unknown by gmailapi.google.com with HTTPREST; Tue, 4 Feb 2025 18:46:37 +0000 From: Andrea Bolognani 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> MIME-Version: 1.0 In-Reply-To: <20250204172242.76889328@elisabeth> Date: Tue, 4 Feb 2025 18:46:37 +0000 X-Gm-Features: AWEUYZm750Kjndm3hia_3V9dolF-dZZo57aiMpSm--LQXe0ikCYtkGJZNhsFtYY Message-ID: Subject: Re: Apparmor (and other) Issues To: Stefano Brivio X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 19sRD87HwOZ7TLQI3FU0Pr8kIKZDcKRTVoVyRelLLL0_1738694798 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Message-ID-Hash: 46XH72X6TMPNB5I2ZF6QKXBRS3NMVZB4 X-Message-ID-Hash: 46XH72X6TMPNB5I2ZF6QKXBRS3NMVZB4 X-MailFrom: abologna@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, 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. > > 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. > 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? > 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. -- Andrea Bolognani / Red Hat / Virtualization