Re: Selinux context type is same for root & normal user both

[Dominick Grift <dominick.grift@defensec.nl>]

Ashish Mishra <ashishm@mvista.com> writes:

> HI Dominick , 
>
> 1) Thanks for pointers . 
>      I will look at the suggestion for login programs. 

I think I understand a little bit what your issue might be now, and if
correct then I believe the focus should be on initial labeling of the filesystem.

>
> 2) The major discrepancy which i am observing is all the folder and files across 
>      filesystem have same context "system_u:object_r:root_t" 
>      Like /etc ,  /var , /bin , /root etc all folders & files have this same context .
>      Attached is the context log for the folder. 

I see, i guess that is rootfs and that it is not labeled initially.
In OpenWrt generally a (readonly) squashfs us used (to boot from) with
overlayfs. The squashfs is labeled at built-time and the root directory of the overlay as well.

I guess that if you want to use rootfs, that you would have to address
initial labeling somehow.

It might help if you tell us a bit about the filesystems used in your
system.



>      
> Any feedback / pointer on point-2 will be helpful .
> I will evaluate the point-1 as suggested . 
>
> Thanks for sharing valuable info. 
> Ashish 
>        
>
> On Wed, Jan 6, 2021 at 7:22 PM Dominick Grift <dominick.grift@defensec.nl> wrote:
>
>  Ashish Mishra <ashishm@mvista.com> writes:
>
>  > Hi Dominick ,
>  >
>  > Thanks for the inputs above.
>  >
>  > 1) w.r.t Monolithic , i am trying refpolicy with monolithic design as suggested.
>  >
>  > 2) I am debugging on the lines you suggested , and prima facie looks like the
>  >     busybox login is being executed here which takes
>  > system_u:object_r:root_t as context
>
>  I do not understand what you mean by that. Context
>  "system_u:object_r:root_t" is a "file" context and I do not understand
>  where you get that from.
>
>  Busybox is a shell with built-in modules AFAIK. It should be labeled
>  "u:object_r:shell_exec_t" IMHO
>
>  >
>  > 3) Can you please let me know which stable source code for
>  >     a) policycoreutils-python    ( to get semanage on target )
>  >     b) setools-console              ( to get seinfo / sesearch on target )
>  >     Please note that we have integrated userland libraries and tools
>  > projects from https://github.com/SELinuxProject/selinux
>  >     But the above mentioned binaries are not present on target.
>
>  https://github.com/SELinuxProject/selinux/releases/download/20200710/selinux-python-3.1.tar.gz
>  https://github.com/SELinuxProject/setools/releases/download/4.3.0/setools-4.3.0.tar.bz2
>
>  >
>  > Request to please let me know input / feedback if i am missing any
>  > obvious things here
>
>  Its hard to say. There are quite a few variables and I am not sure
>  exactly what the current state of your work is and where you want to go
>  (ie what your goals and requirements are)
>
>  I guess you should determine what the login programs used are and then
>  to address those to ensure that login user shells are labeled the way
>  you want them labeled.
>
>  It is probably best to enclose avc denials for any challenge you face.
>
>  >
>  > Thanks ,
>  > Ashish
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  > On Mon, Jan 4, 2021 at 6:21 PM Dominick Grift
>  > <dominick.grift@defensec.nl> wrote:
>  >>
>  >> Ashish Mishra <ashishm@mvista.com> writes:
>  >>
>  >> > Hi Dominick ,
>  >> >
>  >> > Thanks for inputs .
>  >> >
>  >> > a) This is an embedded board which logs in by default as a ROOT user.
>  >> >      Any pointers as to where can i look to debug the cause due to
>  >> > which context is "system_u"
>  >>
>  >> Lack of PAM support or misconfigurated PAM config (pam_selinux needs to
>  >> be present in the appropriate PAM stacks)
>  >>
>  >> >
>  >> > b) Apologies , but can you please help method / approach / debug
>  >> > points by which
>  >> >     -> I can evaluate the expected contexts for root & testuser
>  >> >     -> I can see that the labels are created using ls -alZ .
>  >> >         Is there any other method / debug point to check filesystems
>  >> > are labeled according to the policy.
>  >> >         ( as i am using standard refpolicy to create an default policy
>  >> > on board )
>  >>
>  >> You start by determining the current context of the login user (id -Z
>  >> will print the context of the current shell). Then you determine the
>  >> context of the directory in which the file is created (ls -dZ)
>  >>
>  >> With this information you can query:
>  >>
>  >> sesearch -T -s "type returned by id -Z" | grep "type returned by ls -dZ"
>  >>
>  >> That should return any existing "type_transition" rules where the type
>  >> of the user is the source and the type of the destination directory is a target
>  >>
>  >> >
>  >> >
>  >> > Thanks ,
>  >> > Ashish
>  >>
>  >> The question is whether you want/need IBAC/RBAC on an embedded device
>  >> with only one user (root)
>  >>
>  >> In my policy for OpenWrt (which is a embedded wireless router firmare) i
>  >> do not use IBAC/RBAC either and i just add a rule that say's when the
>  >> login program (sshd) executes a shell then assume that this is a login
>  >> user shell and automatically transition from the sshd context to a specified
>  >> user context)
>  >>
>  >> On embedded devices "modular reference policy" does not make sense to
>  >> use (these devices generally do not have the resources to compile/link
>  >> policy at runtime) IMHO and the "monolithic reference policy" does not work well with
>  >> PAM and users.
>  >>
>  >> But, yes, if you want modular refpolicy on a multi-user system then you
>  >> probably want PAM
>  >>
>  >> --
>  >> gpg --locate-keys dominick.grift@defensec.nl
>  >> Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
>  >> https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
>  >> Dominick Grift
>
>  -- 
>  gpg --locate-keys dominick.grift@defensec.nl
>  Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
>  https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
>  Dominick Grift
>
>

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