On Mon, Oct 13, 2008 at 8:58 PM, Russell Coker <russell@xxxxxxxxxxxx> wrote: > On Tuesday 14 October 2008 14:48, "Justin Mattock" <justinmattock@xxxxxxxxx> > wrote: >> So after using user_r(which I feel is more safe); >> I'm noticing I can't login to sysadm_r. > > That is by design, role transitions to sysadm_r are only permitted from > staff_r, system_r, and unconfined_r. > >> This role seems to be safe in a corporate environment, >> but in my case I'm the only user on this machine as well as >> the admin. > > Then staff_r may be a better choice for your logins. > > Of course there's nothing stopping you from using a ssh client in user_r to > connect to a staff_r session (or sysadm_r if you set a boolean to allow > sysadm_r ssh logins). > > -- > russell@xxxxxxxxxxxx > http://etbe.coker.com.au/ My Blog > > http://www.coker.com.au/sponsorship.html Sponsoring Free Software development > At the moment I'm just booting the system into the given context. ("I've been putting off starting SELinux with a desktop-manager") As for runing in user_r; seems to be a better choice but if I have to do any compiling or editing I have to reboot and put SELinux into permissive mode to do so.(unless its possible to run the system in user_r then use newrole to change to sysadm to make any kind of adjustments). As for ssh, I did notice a few weeks ago that my machine I was ssh'ing into was put into user_r by default. If I had no way of disabling the policy on the local machine it would of been next to impossible to make any kind of adjustments, making the argument of running in staff_r probably the right choice for capturing any kind of debug logs and so forth, in a safe and secure environment. -- Justin P. Mattock -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.