Re: [PATCH v3 0/1] selinux: Transition to pasta_t in containers

[Stefano Brivio <sbrivio@redhat.com>]

On Tue, 20 May 2025 04:37:41 -0600
Max Chernoff <git@maxchernoff.ca> wrote:

> Hi Stefano,
> 
> On Mon, 2025-05-19 at 09:39 +0200, Stefano Brivio wrote:
> > On Sat, 17 May 2025 03:34:42 -0600
> > Max Chernoff <git@maxchernoff.ca> wrote:  
> > > On Fri, 2025-05-16 at 18:11 +0200, Stefano Brivio wrote:  
> > > > #============= pasta_t ==============
> > > > allow pasta_t container_runtime_t:dir { open read search };
> > > > allow pasta_t container_runtime_t:file read;
> > > > allow pasta_t container_runtime_t:lnk_file read;
> > > > allow pasta_t container_t:lnk_file read;
> > > >
> > > > If I add those rules, everything works  
> 
> > > I guess the options are:
> > >
> > > 1. Add the above rules to the pasta SELinux policy
> > >
> > > 2. Have Podman change the context of /proc/self/ns/net to pasta_t
> > >
> > > 3. Have Podman pass a file descriptor to the netns instead of the path
> > >    to the netns.
> > >
> > > (1) is arguably the least secure, but is probably fine in practice?  
> >
> > Well:
> >
> > 2. is probably the most restrictive but it doesn't really feel
> >    correct to me (pasta is not, at least conceptually, the exclusive
> >    user of the network namespace link)
> >
> > 3. is pretty much a way to dodge LSM policies (SELinux / AppArmor can't
> >    see this, done)
> >
> > ...so I would opt for 1.
> >
> > I see why you mention it's less secure: we didn't really want to be
> > able to open and read *any* container_runtime_t:dir or
> > container_t:lnk_file. But that's not really the part of "fine-grained"
> > security that we typically delegate to SELinux anyway.  
> 
> Alright, works for me. I've added those rules into the policy in the
> following commit.

Thanks, this looks ready for merging, minus the spec file problem
(which we can also solve in another change, but I'd like to merge them
together).

Paul, maybe you want to give this version another try as well.

> > ...so I guess the only remaining point, other than adding those rules,
> > is to figure out why %selinux_relabel_post isn't enough and what we can
> > add to the spec file instead. I'll try to have a look at it within a
> > couple of days unless you find an explanation / solution before then.  
> 
> I've looked through the code and I'm also lost as to why
> %selinux_relabel_post isn't working. I'll try taking a look again
> tomorrow, but I doubt that I'll be able to figure it out.

I haven't had the chance yet, I'll tell you if / as soon as I do. My
first debugging step would have been to run 'fixfiles' manually, by the
way, after changing the file contexts...

-- 
Stefano