Ashish Mishra <ashishm@xxxxxxxxxx> 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@xxxxxxxxxxx> wrote: > > Ashish Mishra <ashishm@xxxxxxxxxx> 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@xxxxxxxxxxx> wrote: > >> > >> Ashish Mishra <ashishm@xxxxxxxxxx> 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@xxxxxxxxxxx > >> 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@xxxxxxxxxxx > 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@xxxxxxxxxxx Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098 Dominick Grift
