Re: [CentOS-devel] Making the redhat selinux-policy repository
publicly available
by Zdenek Pytela
On Tue, Jul 11, 2023 at 10:37 PM Troy Dawson <tdawson(a)redhat.com> wrote:
> On Tue, Jul 11, 2023 at 12:50 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
>
>> On Tue, Jul 11, 2023 at 9:31 AM Troy Dawson <tdawson(a)redhat.com> wrote:
>> >
>> > On Tue, Jul 11, 2023 at 4:28 AM Daan De Meyer <daan.j.demeyer(a)gmail.com>
>> wrote:
>> >>
>> >> Hi,
>> >>
>> >> It seems that the selinux-policy rpm is built from
>> >> git@gitlab.cee.redhat.com:SELinux/selinux-policy.git which seems to be
>> >> a redhat internal repository. More specifically, if I try to checkout
>> >> the commit listed in the selinux-policy spec
>> >> (
>> https://gitlab.com/redhat/centos-stream/rpms/selinux-policy/-/blob/c9s/se...
>> )
>> >> in the fedora-selinux repository cloned from github, I get an error
>> >> saying that the commit does not exist. It would be great if the
>> >> repository containing this commit was publicly available and open for
>> >> external contributors just like all the other packages in CentOS
>> >> Stream. Is it possible to make this happen?
>> >
>> >
>> > I'm not the selinux-policy maintainer, so I can't comment on where they
>> work on the selinux-policy source code.
>> >
>> > But this is how I get the sources, if that is what you are ultimately
>> looking for.
>> >
>> > centpkg clone selinux-policy
>> > cd selinux-policy
>> > centpkg sources
>> > or if you want to know where they really are
>> > centpkg -v sources
>> > This shows it to be coming from
>> >
>> https://sources.stream.centos.org/sources/rpms/selinux-policy/selinux-pol...
>> >
>> > The sources information is found in the sources file
>> >
>> https://gitlab.com/redhat/centos-stream/rpms/selinux-policy/-/blob/c9s/so...
>> >
>> > I know this isn't exactly what you asked for, but I hope it still helps.
>> >
>>
>> I think the idea is that having the Git repository in a public
>> location would allow the CentOS Hyperscale SIG to contribute to the
>> SELinux policy in a meaningful way.
>>
>
> Ah, ok. That makes sense.
> As I said, I'm not the maintainer so I don't know why it's where it is.
> So I'll step out of the conversation.
>
Hi,
I am one of the selinux-policy maintainers. Currently, repository for
Fedora is at github.com and RHEL sources are in an internal repo. We have
already discussed moving centos stream sources to some of the public
repositories, but it did not happen. Currently we are discussing it again,
there are a few options how to do so.
To get just the latest repository content, steps described by Troy should
work. Additionally, most of the upstream work is done in Fedora and anyway
every new commit should go to Fedora first, RHEL content is mostly a subset
of Fedora, there are very few differences.
--
Zdenek Pytela
Security SELinux team
1 week, 4 days
permitting reading files in /proc owned by a user?
by James Ralston
I am writing an SELinux module to confine a commercial VPN
application.
The application consists of two server processes that run as root,
with a “tray” process that users run. The tray process talks to the
server processes via various mechanisms, including D-Bus.
I have both server processes running in the myvpn_t domain.
For now, my module is in permissive mode, so that I can work through
the various SELinux denials and see how to best allow (or in some
cases, dontaudit) the actions the server processes take.
I noticed that the server processes were attempting to perform certain
actions on unconfined_t directories/files. From audit2allow:
allow myvpn_t unconfined_t:dir search;
allow myvpn_t unconfined_t:file read;
allow myvpn_t unconfined_t:lnk_file read;
Looking through the raw AVC audit messages, the issue is that once the
tray process contacts the server processes, the server processes begin
watching the health of the tray process, by reading (e.g.):
/proc/12345/exe
…where 12345 is the pid of the tray process.
(My guess is that the server processes are attempting to verify not
just that the tray process is still running, but that it’s still the
tray process, and not some other process that grabbed the same pid
after the tray process exited.)
Because our users run in unconfined_t, the /proc/12345 directory (and
files underneath it) are owned by the user running the tray and are in
the unconfined_t context.
There are a bunch of macros to permit domains to perform various
operations in /proc, but they all assume the file context is proc_t.
So these macros aren’t really designed to permit access to the
individual pid directories in /proc.
If I deny (dontaudit) these accesses, I will likely break the server
processes, as they will no longer be able to monitor the tray. But I
see no way to grant them the access they want without doing as
audit2allow suggests:
allow myvpn_t unconfined_t:dir search;
allow myvpn_t unconfined_t:file read;
allow myvpn_t unconfined_t:lnk_file read;
…which will grant the server processes the ability to read/search
unconfined_t files/directories *anywhere*, not just in /proc. That’s
undesirable.
Is there some way to grant the above access, but only if the
files/directories are in /proc?
Alternatively, it occurred to me that a better solution might be to
set up a transition so that when a user invokes the tray executable,
it transitions to (e.g.) myvpn_user_t. But I can find vanishingly few
examples of user-level transitions like this anywhere else in Fedora
and/or RHEL, so I don’t know if it’s something to be avoided.
(xserver_exec_t (/usr/libexec/Xorg) transitioning to xserver_t when
invoked by a user context is the only obvious example I found.)
Is there a better solution that I’m not seeing?
1 month