Re: SELinux: creating a per-user confined domain

[Roberto Sassu]

Thanks all for replies.
I have modified the policy by using the template
userdom_unpriv_user_template() and everything is ok.
Talking about different labels for each home directory i'm not sure but if
all users domains have access to the default type user_home_dir_t
access control on files under /home will be based on DAC mechanism.
My effort is focused on trying to evaluate if it is possible with SELinux to
protect files using as criteria for access decision the combination user
identity-application-identity.
For example i want to protect the user's private key allowing the access
only to the program "ssh" ran by the user "user1".
In my policy i created the domain "user1_t" which is set by the login
program when "user1" logs in the system. Then i called the interface
ssh_basic_client_template(user1, user1_t, user1_r) which creates the derived
domain user1_ssh_t at the time user1 executes the "ssh" command. The file
$home/.ssh/id_rsa could be labeled with a unique label and a specific rule
can be added to allow only the user1_ssh_t domain to read the key.
Denying to users the ability to set security contexts, does this policy
create a separation between the ssh application and the others ran by the
same user?







On Tue, Sep 15, 2009 at 5:40 PM, Daniel J Walsh <dwalsh(a)redhat.com&gt; wrote:

>  On 09/15/2009 09:57 AM, Roberto Sassu wrote:
>  > Hello all
>  >
>  > i'm new to SELinux. I'm trying to create per-user domains in a system
>  running
>  > Fedora 11 with the targeted policy enabled. The reason for that is that i
>  need
>  > to create transitions to different domains when users start the same
>  > application.
>  > I followed these steps:
>  > - written my custom policy module(posted as attachment) in order to
>  create new
>  > roles user1_r, user2_r with the default domains user1_t and user2_t;
>  > - added to the system new selinux users user1_u and user2_u;
>  > - added to the system the new linux users user1 and user2;
>  > - associated user1 with user1_u and user2 with user2_u;
>  > - labeled home directories respectively with types user1_home_t and
>  > user2_home_t
>  > - created the two files user1_u and user2_u in
>  > /etc/selinux/targeted/contexts/users;
>  >
>  > Then i tried to connect in local to the ssh server from root to the user1
>  but
>  > it rejected the connection with this log messages (but no AVC warnings):
>  >
>  > Sep 15 15:39:19 seclab05 sshd[5014]: Accepted password for user1 from ::1
>  port
>  > 53163 ssh2
>  > Sep 15 15:39:19 seclab05 sshd[5014]: pam_selinux(sshd:session):
>  conversation
>  > failed
>  > Sep 15 15:39:19 seclab05 sshd[5014]: pam_selinux(sshd:session): No
>  response to
>  > query: Would you like to enter a security context? [N]
>  > Sep 15 15:39:19 seclab05 sshd[5014]: pam_selinux(sshd:session): Unable to
>  get
>  > valid context for user1
>  > Sep 15 15:39:19 seclab05 sshd[5014]: pam_unix(sshd:session): session
>  opened
>  > for user user1 by (uid=0)
>  > Sep 15 15:39:19 seclab05 sshd[5014]: error: PAM: pam_open_session():
>  > Authentication failure
>  > Sep 15 15:39:19 seclab05 sshd[5014]: error: ssh_selinux_setup_pty:
>  > security_compute_relabel: Invalid argument
>  >
>  > If putting the system in permissive mode the connection was successful
>  but the
>  > security context after login was:
>  system_u:system_r:unconfined_t:s0-s0:c0.c1023
>  > Any suggestions? Thanks in advance.
>  >
>  >
>  >
>  >
>  > ------------------------------------------------------------------------
>  >
>  > --
>  > fedora-selinux-list mailing list
>  > fedora-selinux-list(a)redhat.com
>  > https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>
>  You probably need to create /etc/selinux/targeted/context/user1 and user2
>
>  Base these off of xguest
>
>  I am not crazy about having home content variable between users, I think
>  this is a waste of time.  Others disagree.
>
>  --
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>