Re: [gentoo-hardened] Portage-related AVCs

[Jason Zaman]

On Thu, Nov 24, 2016 at 09:13:35PM +0000, Robert Sharp wrote:
> On 24/11/16 17:07, Jason Zaman wrote:
> > That warning is harmless, i'll remove the line from the policy later.
> > for now ignore it or manually remove the line to silence the warning.
> > http://blog.perfinion.com/2016/10/selinux-userspace-26-released/
>
> Sorry Jason, but I am not making much progress. I have emerged as you
> suggested with the 20151208-r6 versions (and setools4). When I repeat
> the search for portage_sandbox I get the same results as before:

OH! I just looked harder at my configs, I do have this locally on my
laptop:
allow portage_sandbox_t portage_tmp_t:dir { relabelfrom relabelto };
I hadnt added it to the policies yet tho. I forgot why I needed it :(.
Do all packages fail without it or only some?
I will add it to the next policy release, I guess it was my fault all
along :-P, sorry about that.

> # sesearch -s portage_sandbox_t -t portage_tmp_t -A
> allow portage_sandbox_t non_auth_file_type:dir { search read lock
> getattr ioctl open };
> allow portage_sandbox_t non_auth_file_type:file { read lock ioctl open
> getattr };
> allow portage_sandbox_t non_auth_file_type:lnk_file { read getattr };
> allow portage_sandbox_t portage_tmp_t:dir { rename search setattr read
> lock create reparent getattr write ioctl link rmdir remove_name unlink
> open add_name };
> allow portage_sandbox_t portage_tmp_t:fifo_file { rename setattr read
> lock create getattr write ioctl link unlink open append };
> allow portage_sandbox_t portage_tmp_t:file { rename execute setattr read
> lock create getattr execute_no_trans write relabelfrom ioctl link
> relabelto unlink open append };
> allow portage_sandbox_t portage_tmp_t:lnk_file { rename setattr read
> lock create getattr write ioctl link unlink };
> allow portage_sandbox_t portage_tmp_t:sock_file { rename setattr read
> lock create getattr write ioctl link unlink open append };
>
> There is still no relableto/from in the dir rule. I am not sure the
> module rebuild worked. I tried the semodule -B again with -v and it all
> happens rather quickly:
>
> # semodule -B -v
> Committing changes:
> libsemanage.add_user: user system_u not in password file
> Ok: transaction number 0.
>
> Doesn't seem like it spent long rebuilding all those policies, but then
> I wouldn't know if it is supposed to be quick?
>
> Also, there doesn't seem to be a very easy way to confirm what policy
> version is in place? I once saw a listing from semodule -l that included
> version information but it doesn't happen on my system.
The policy versions that semodule reports are what the policy_module
line in the source which was annoying to look up too. newer userspace is
based off CIL which doesnt have those version numbers at all anymore.

-- Jason