I have switched the user role of an existing account to xguest_u thus enabling kiosk mode for this specific user. Works like a charm, thanks. Now i only need to permit ssh access.
According to :
# grep ssh /var/log/audit/audit.log | audit2allow -R
class sock_file write;
#============= guest_t ==============
allow guest_t devlog_t:sock_file write;
#============= xguest_t ==============
How could i give the xguest user also ssh access in addition to web browsing with firefox?
My response was that he should create a policy module to add these allow rules by executing
# grep ssh /var/log/audit/audit.log | audit2allow -R -M myssh
# semodule -i myssh.pp
Peter responded that this worked perfectly.
I decided to examine this further.
I would have used:
Which allows the xguest_t and more specifically the ssh application to send syslog messages.
Allows xguest_t and ssh to connect to ssh ports.
# semanage port -l | grep ssh
ssh_port_t tcp 22
I was somewhat surprised that Peter did not need to add:
# These two lines allow support for labeled packets to flow across the machine.
# Allows xguest to send/recv packets on all interfaces.
# Allows xguest to send/recv packets too all nodes.
Investigating further, the xguest module includes the following interface:
This interface allows xguest_t to do translate UIDs to user names on machines using network logins. The command
# ls -l
The auth_use_nsswitch interface adds allow rules for accessing DNS for resolving hostnames (dns_port_t) and allow rules for accessing LDAP (ldap_port_t). auth_use_nsswitch also can adds rules allowing access to NIS/YPBIND ports, but this is protected by the allow_ypbind boolean.
We policy developers should add a new boolean (use_ldap_auth?) to turn off ldap access for confined applications on machines that do not use LDAP password information.
What about minimal privilege?
Peter added connect access to ssh_port_t for any application that xguest runs. xguest_t uses minimal privilege to access httpd_port_t. When xguest_t tries to access the Internet, only firefox is allowed access, all other apps are denied. A more secure solution for Peter might have been to write a new policy for the /usr/bin/ssh command.
He could have labeled /usr/bin/ssh ssh_exec_t, and wrote policy to transition to xguest_t to ssh_t. ssh_t could be the only application that connects to ssh_port_t ports. Giving Peter true least privilege. No other applications run by xguest_t would be able to talk to port ssh_port_t. Problems? This adds a great deal of complexity.
Should Peter label /usr/bin/scp ssh_exec_t? stunnel?
If Peter labels scp ssh_exec_t, can it read xguest_home_t? xguest_tmp_t? Random files on his machine? If he copies file to his local machine, can it what to his home directory? (xguest_home_t)?
Working towards true Least privilege is a noble goal, but with potentially a large increase in complexity.
Depending on your security goals, SELinux gives you the flexibility to get the security you need.