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
