Re: Fwd: strange issue with name-base type trans

[Dominick Grift <dac.override@gmail.com>]

James Carter <jwcart2@gmail.com> writes:

> Sorry, email problems has made life a bit difficult over the past
> week. Steve had to forward this to me.
>
> So far, I am unable to duplicate what you are seeing.

You can try it with my dssp3 policy:

git clone git://defensec.nl/dssp3.git
cd dssp3
[kcinimod@brutus dssp3 (master=)]$ secilc `find . -name "*.cil"`
[kcinimod@brutus dssp3 (master=)]$ sesearch policy.32 -T | grep sudo | grep tmp
type_transition sudo.subj file.log:file pam.faillog.log btmp;
type_transition sudo.subj file.tmp:file sudo.tmp;
[kcinimod@brutus dssp3 (master=)]$ sed -i 's/(call obj_type_transition_tmp_fixme (subj file))/(call obj_type_transition_tmp (subj file "*"))/' poli
cy/app/s/sudo.cil
[kcinimod@brutus dssp3 (master *=)]$ secilc `find . -name "*.cil"`
[kcinimod@brutus dssp3 (master *=)]$ sesearch policy.32 -T | grep sudo | grep tmp
type_transition sudo.subj file.log:file pam.faillog.log btmp;
type_transition sudo.subj file.tmp:file sudo.tmp ARG3;

Note the "ARG3" in the latter result

>
> I tried to create policy similar to what you are doing, but I am
> getting the correct results. The following is what I tested (the
> attached policy is the full policy).
>
> (macro trans_base ((type ARG1)(type ARG2)(type ARG3)(class ARG4)(name ARG5))
>     (typetransition ARG1 ARG2 ARG4 ARG5 ARG3)
> )
>
> (block b0
>        (type t0)
>        (macro trans_add1 ((type ARG1)(type ARG2)(class ARG3)(name ARG4))
>           (call trans_base (ARG1 t0 ARG2 ARG3 ARG4))
>        )
> )
>
> (block b1
>        (type t1a)
>        (type t1b)
>        (type t1c)
>        (type t1d)
> )
>
> (in b1
>     (macro trans_parent1a ((type ARG1)(class ARG2))
>            (call .b0.trans_add1 (ARG1 t1a ARG2 "thisworks1a"))
>     )
>     (macro trans_parent2a ((type ARG1)(class ARG2)(name ARG3))
>            (call .b0.trans_add1 (ARG1 t1b ARG2 ARG3))
>     )
> )
>
> (call .b1.trans_parent1a (.b1.t1c CLASS))
> (call .b1.trans_parent2a (.b1.t1d CLASS "thisdoesntwork2a"))
>
> I then compiled and decompiled the policy:
>   secilc -v -v -v -o test3.bin typetransition_problem_3.cil
>   checkpolicy -b -C -o test3.cil test3.bin
>
> In test3.cil, there is the following typetransition rules (which are
> as they should be):
>   (typetransition b1.t1c b0.t0 CLASS thisworks1a b1.t1a)
>   (typetransition b1.t1d b0.t0 CLASS thisdoesntwork2a b1.t1b)
>
> I must be doing something slightly different from what your policy is
> doing and I could use help in figuring out what that might be.
>
> Jim
>
> ---------- Forwarded message ---------
> From: Dominick Grift <dominick.grift@defensec.nl>
> Date: Mon, Feb 24, 2020 at 12:07 PM
> Subject: strange issue with name-base type trans
> To: <selinux@vger.kernel.org>
>
>
> The scenario:
>
> (in user
> (macro obj_type_transition_mytmp1 ((type ARG1)(class ARG2))
> (call .file.tmp_obj_type_transition (ARG1 tmp ARG2 "thisworks")))
> (macro obj_type_transition_mytmp2 ((type ARG1)(class ARG2)(name ARG3))
> (call .file.tmp_obj_type_transition (ARG1 tmp ARG2 ARG3))))
>
> (call .user.obj_type_transition_mytmp1 (user.subj chr_file))
> (call .user.obj_type_transition_mytmp2 (user.subj chr_file "thisdoesntwork"))
>
> The outcome:
>
> [root@myguest ~]# sesearch -T -s user.subj -c chr_file,blk_file | grep tmp
> type_transition user.subj file.tmp:chr_file user.tmp ARG3;
> type_transition user.subj file.tmp:chr_file user.tmp thisworks;
>
> [root@myguest ~]# uname -a
> Linux myguest 5.5.5-200.fc31.x86_64 #1 SMP Wed Feb 19 23:28:07 UTC
> 2020 x86_64 x86_64 x86_64 GNU/Linux
> [root@myguest ~]# rpm -qa libsepol
> libsepol-3.0-3.fc32.x86_64
> [root@myguest ~]# rpm -qa libselinux
> libselinux-3.0-3.fc32.x86_64
>
> --
> gpg --locate-keys dominick.grift@defensec.nl
> Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
> Dominick Grift
>
>

-- 
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift