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
