From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTP id 3AA375A026D for ; Wed, 7 Jun 2023 13:38:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1686137897; 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=AtCW71QCRcUb2V8Wft1oEPej32B62qYEt7GZzjxcpWM=; b=WvpZl/SVo+i9C6P1wV2E8euu5PUhgqvgW0mINN6HsJhps5HT2YYWZgFpIDobEhvhB0T+wz FMsYxxmHVYVd/X74UEjbicdrmDspE2cYvc97ORDmOLGAMYHZNKVdMG4DwlVHTSLyBdcEKg vBTvb/3l2LtKQ4yqhlNg3aNCj29GTOc= Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-628-5wRGKpirNPapSe9CumU7JA-1; Wed, 07 Jun 2023 07:38:16 -0400 X-MC-Unique: 5wRGKpirNPapSe9CumU7JA-1 Received: by mail-ed1-f70.google.com with SMTP id 4fb4d7f45d1cf-514bcf60cd1so788569a12.2 for ; Wed, 07 Jun 2023 04:38:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686137895; x=1688729895; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=AtCW71QCRcUb2V8Wft1oEPej32B62qYEt7GZzjxcpWM=; b=H1uJmMi9apvjgUo9NSKcIxPMNAej6fRN+qLark7I/BxbwRiBBrJH6db3TV0l2mLgTt +fUEOGnHF20ijzrwlZyYOzk6d6lCpfv9YpUj2gauG2r+tD4SdKuTV7vuikXp+SbDxXXo S51KkJweoHDuI4qi7sU0imdU6e/C9ZwjQzMVaaS9TUhpywsig6+9wNAcBlDQaCRjfS4E +E+rz4uGNduSRWvTUvSqQMViLqr16bSoAD9SvqF3KyGIgqJfDDKSxedgh9Xf7U6KgkJh jGEd8drpb2HouZGWUg827XAQN62h8fdJVG79sPcRVQkuqL8bTkTSRNnX220axT7ZpdGF +C+Q== X-Gm-Message-State: AC+VfDxoQiOVWlz61ah/0ULv4BUsqR9Vmic46rm6MgWrobDrXiiYJVpf 5MWdCx2o/qznZn4huM5RxJfAvrnVjPXxoVhdSY+recrdSq7HNwkOrvPsapsxhhSNSq63i4QDv9L UPsRKlSb8GmJs X-Received: by 2002:a17:907:1c0c:b0:965:6075:d100 with SMTP id nc12-20020a1709071c0c00b009656075d100mr5849270ejc.39.1686137895020; Wed, 07 Jun 2023 04:38:15 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4OqV8F9onmxxdBvOP8Zj86ZDVjKX2+gdXcm9nZeXN8sHZ264Sp76OdkHGghTgH3VeADmibBQ== X-Received: by 2002:a17:907:1c0c:b0:965:6075:d100 with SMTP id nc12-20020a1709071c0c00b009656075d100mr5849251ejc.39.1686137894669; Wed, 07 Jun 2023 04:38:14 -0700 (PDT) Received: from [10.43.2.36] (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id b13-20020a056402138d00b00516654bf182sm2901805edv.41.2023.06.07.04.38.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Jun 2023 04:38:13 -0700 (PDT) Message-ID: <39b5445f-3126-db92-01cd-60efb2dc25d1@redhat.com> Date: Wed, 7 Jun 2023 13:38:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH 0/2] Introduce --log-fd option To: Stefano Brivio References: <20230606225836.63aecebe@elisabeth> From: =?UTF-8?B?TWljaGFsIFByw612b3puw61r?= In-Reply-To: <20230606225836.63aecebe@elisabeth> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Message-ID-Hash: A3GHUCWNEPFAJOFOW7FJT57QN7UEEE54 X-Message-ID-Hash: A3GHUCWNEPFAJOFOW7FJT57QN7UEEE54 X-MailFrom: mprivozn@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: 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 6/6/23 22:58, Stefano Brivio wrote: > Hi, > > On Tue, 6 Jun 2023 13:41:28 +0200 > Michal Privoznik wrote: > >> The idea behind this is so that libvirt can create the log file, set all >> DAC/SELinux labels and just pass pre-opened FD to passt. >> >> You can view my WIP patches for libvirt here: >> >> https://gitlab.com/MichalPrivoznik/libvirt/-/commit/5bbe40087d6888a7c4031a2224731523e117c072 > > Thanks for the implementation... and also for taking care of the > details! > > I'm not really enthusiastic about the security implications of this > approach, but _if it's the only reasonable way to solve this_, I won't > certainly stand in the way of progress. The series looks mostly good to > me, I have only a few nits, reported in the single replies. > > This adds a further interfacing mode between passt and the parent > process, which makes me a bit uncomfortable in general. > > Specifically, if the parent process runs as root, this gives a rogue > passt process a way to write potentially unlimited amounts of data to > essentially any place (minus _some_ checks implemented by Linux Security > Modules). And a rogue passt process doesn't necessarily imply a rogue > parent, so this is additional surface. Well, is it any different to when libvirt would create the file, set perms and then let passt open() it? In fact, I find passing FD safer because libvirt doesn't need to set up perms/owner and can leave the log file be owned by root:root with 0600 mode, or any other user that libvirtd runs under. > > Oh, and by the way of LSMs, we kind of bypass stuff like this. > > For a non-rogue passt process, if the parent runs as root, I don't see > any additional attack scenario -- the parent could do anything it wants > anyway. But if the parent runs as regular user, there are a few > additional ways to cause passt to misbehave by passing in a file > descriptor that doesn't correspond to a file, or that's opened by other > processes, without any mediation by the filesystem (which is generally > speaking not under control of unprivileged users). So an attacker can cause libvirtd to pass an FD that doesn't belong to the log file opened by libvirtd? Interesting, I though that's impossible. I mean, it's sort of a goal we're working towards with QEMU - libvirt opens FDs and then just pass them to QEMU. So if it's really unsafe, we should re-evaluate our goal. > > I'd rather much prefer the more common approach of defaulting, or > suggesting to the user, to write to a temporary filesystem, available > under most distributions under /run or /var/run. Is that really > unfeasible? It if feasible. I just thought that when users want their logs to reside under some special path that libvirtd has access to, but not passt then we might use FD passing. > > I'm thinking that libvirt already needs a specific directory for passt > to use (socket and PID files). What if logFile, other than an absolute > path, supported a relative path? This logic might perhaps apply to > other helpers or external programs too. That's tangent to this problem. > > By the way, passt ships with AppArmor and SELinux example policies, > which are also included in packages. They would need at least a quick > review, probably some edits, and some basic tests. Thinking of those, a > relative path would also simplify things. > Ah, completely forgot about those. Yeah, they might need tweaking even if we decide to go this route. Michal