Fwd: strange issue with name-base type trans

Fwd: strange issue with name-base type trans

[James Carter]

[-- Attachment #1: Type: text/plain, Size: 2790 bytes --]

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.

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

[-- Attachment #2: typetransition_problem_3.cil --]
[-- Type: application/octet-stream, Size: 2142 bytes --]

(class CLASS (PERM))
(classorder (CLASS))
(sid SID)
(sidorder (SID))
(user USER)
(role ROLE)
(type TYPE)
(category CAT)
(categoryorder (CAT))
(sensitivity SENS)
(sensitivityorder (SENS))
(sensitivitycategory SENS (CAT))
(allow TYPE self (CLASS (PERM)))
(roletype ROLE TYPE)
(userrole USER ROLE)
(userlevel USER (SENS))
(userrange USER ((SENS)(SENS (CAT))))
(sidcontext SID (USER ROLE TYPE ((SENS)(SENS))))

;;
;; Report by Dominick Grift <dominick.grift@defensec.nl>
;;
;;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;
;;

(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"))

;; Compile and decompile:
;;   secilc -v -v -v -o test3.bin typetransition_problem_3.cil
;;   checkpolicy -b -C -o test3.cil test3.bin
;; In test3.cil, we have the following:
;;   (typetransition b1.t1c b0.t0 CLASS thisworks1a b1.t1a)
;;   (typetransition b1.t1d b0.t0 CLASS thisdoesntwork2a b1.t1b)

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

[Dominick Grift]

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

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

[James Carter]

On Thu, Feb 27, 2020 at 2:51 PM Dominick Grift <dac.override@gmail.com> wrote:
>
> 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 found the problem. In dssp3/policy/user/user_runtimeuser.cil there
is the following macro definition.

    (macro obj_type_transition_runtimeuser ((type ARG1)(class ARG2)(name ARG2))
           (call .file.runtimeuser_obj_type_transition
                 (ARG1 runtimeuser ARG2 ARG3)))

Notice that ARG2 is used twice and ARG3 is not actually an argument
and is taken as a name.

There are a couple of bugs here. First, CIL should give an error for
the duplicate argument names and, second, CIL should be checking if a
name is actually a macro parameter before it checks whether that name
is already in the name symbol table.

You were seeing what you saw because the macro above is never called
but it does put ARG3 into the symbol table so that it is not
recognized as a parameter later.

Jim

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

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 2496 bytes --]

On Wed, Mar 04, 2020 at 01:53:47PM -0500, James Carter wrote:
> On Thu, Feb 27, 2020 at 2:51 PM Dominick Grift <dac.override@gmail.com> wrote:
> >
> > 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 found the problem. In dssp3/policy/user/user_runtimeuser.cil there
> is the following macro definition.

Thanks! I feel a little bad that it is a bug in my policy that brings this to light (and that I couldnt find the bug in the policy myself)
Hopefully this event will help improve things.

Thanks again

> 
>     (macro obj_type_transition_runtimeuser ((type ARG1)(class ARG2)(name ARG2))
>            (call .file.runtimeuser_obj_type_transition
>                  (ARG1 runtimeuser ARG2 ARG3)))
> 
> Notice that ARG2 is used twice and ARG3 is not actually an argument
> and is taken as a name.
> 
> There are a couple of bugs here. First, CIL should give an error for
> the duplicate argument names and, second, CIL should be checking if a
> name is actually a macro parameter before it checks whether that name
> is already in the name symbol table.
> 
> You were seeing what you saw because the macro above is never called
> but it does put ARG3 into the symbol table so that it is not
> recognized as a parameter later.
> 
> Jim

-- 
gpg --locate-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 2504 bytes --]

On Wed, Mar 04, 2020 at 01:53:47PM -0500, James Carter wrote:
> On Thu, Feb 27, 2020 at 2:51 PM Dominick Grift <dac.override@gmail.com> wrote:
> >
> > 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 found the problem. In dssp3/policy/user/user_runtimeuser.cil there
> is the following macro definition.
> 
>     (macro obj_type_transition_runtimeuser ((type ARG1)(class ARG2)(name ARG2))
>            (call .file.runtimeuser_obj_type_transition
>                  (ARG1 runtimeuser ARG2 ARG3)))
> 
> Notice that ARG2 is used twice and ARG3 is not actually an argument
> and is taken as a name.
> 
> There are a couple of bugs here. First, CIL should give an error for
> the duplicate argument names and, second, CIL should be checking if a
> name is actually a macro parameter before it checks whether that name
> is already in the name symbol table.
> 
> You were seeing what you saw because the macro above is never called
> but it does put ARG3 into the symbol table so that it is not
> recognized as a parameter later.

It should have been called though AFAIK some lines above:

https://defensec.nl/gitweb/dssp3.git/commitdiff/113b367e6bba8c18166eb34b6b67858fc17a0a8d#patch3

Regardless I can confirm that this fixes the issue

> 
> Jim

-- 
gpg --locate-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]