We are debating the default user context for fedorapeople.org:
Right now users are unconfined_t. This would, ostensibly, let them do a lot. However, we have fedorapeople set up to isolate user tempdirs and every place a user can write to is mounted noexec,nosuid - so there is no place to run anything that isn't already on the system.
We're wondering if we should move them to either:
user_t
or
guest_t
User_t sets: X Windows Login and terminal login, nosetuid, noexec in homedir
As we have things currently configured this would not involve much in the way of a change to how users can operate on fedorapeople.org
Guest_t sets: Terminal login, nosetuid, nonetwork, noxwindows, noexec in homedir
X is not really an issue, obviously. So the big difference here is that outbound network connections would not be allowed with guest_t.
The debate is really over network access. We know that some folks tunnel through fedorapeople.org for irc and they login there to rsync things to this space for personal hosting, etc.
So there are some legit reasons for outbound network connections. However, it is not obvious that those reasons are within the scope for what fedorapeople.org is supposed to be used.
And that is the more or less it - does anyone have any suggestions/thoughts?
-sv
On Tue, 2012-03-27 at 17:17 -0400, seth vidal wrote:
And that is the more or less it - does anyone have any suggestions/thoughts?
You don't have to limit yourself to picking between user_u or guest_u. You can create another role, such as "fedorauser_u" that is basically guest_u, except you can then add specific policies via SELinux roles, such as:
irc_role(fedorauser_t, fedorauser_r)
Which should let them run an IRC client such as irsii.
On the other hand, just setting user_u is a good start and a lot less work.
Best,
On Tue, 27 Mar 2012 17:33:26 -0400 Konstantin Ryabitsev icon@fedoraproject.org wrote:
On Tue, 2012-03-27 at 17:17 -0400, seth vidal wrote:
And that is the more or less it - does anyone have any suggestions/thoughts?
You don't have to limit yourself to picking between user_u or guest_u. You can create another role, such as "fedorauser_u" that is basically guest_u, except you can then add specific policies via SELinux roles, such as:
irc_role(fedorauser_t, fedorauser_r)
Which should let them run an IRC client such as irsii.
On the other hand, just setting user_u is a good start and a lot less work.
Except it is more or less where we are now.
ie: user can run stuff but they cannot put any exec or suid files in any place they can write.
The debate is not about whether or not to enable this - it is about whether we need to allow network connections at all.
Allowing irc out or ssh tunnels is not significant more safety over just allowing general network communication, afaict.
-sv
On Tue, 2012-03-27 at 17:35 -0400, seth vidal wrote:
Except it is more or less where we are now.
ie: user can run stuff but they cannot put any exec or suid files in any place they can write.
The debate is not about whether or not to enable this - it is about whether we need to allow network connections at all.
Allowing irc out or ssh tunnels is not significant more safety over just allowing general network communication, afaict.
It's not quite like that. E.g. if we do fedora_u with irc_role(), then the person would be allowed to execute a binary labelled with irc_exec_t, which would then be allowed to connect to IRC ports. Without executing that binary, the user would not be able to connect to IRC ports, so no ssh-forwarding or just "telnet 6667".
Let me verify this in my VM, though, before I'm forced to insert my foot into my mouth. :)
Best,
On Tue, 2012-03-27 at 17:43 -0400, Konstantin Ryabitsev wrote:
Let me verify this in my VM, though, before I'm forced to insert my foot into my mouth. :)
Yes, it works just as I thought. If you want to test it out:
testguest.te: -------------------------------- policy_module(testguest, 1.0.0) role testguest_r; irc_role(testguest_r, testguest_t) userdom_restricted_user_template(testguest) gen_user(testguest_u, user, testguest_r, s0, s0) --------------------------------
make -f make -f /usr/share/selinux/devel/Makefile testguest.pp semodule -i testguest.pp cd /etc/selinux/targeted/contexts/users cat guest_u | sed 's/guest_u/testguest_u/g' > testguest_u useradd bob passwd bob usermod -Z testguest_u bob
As a result:
[bob@moppet ~]$ whoami bob [bob@moppet ~]$ id -Z testguest_u:testguest_r:testguest_t:s0 [bob@moppet ~]$ telnet irc.freenode.org 6667 Trying 94.125.182.252... telnet: connect to address 94.125.182.252: Permission denied
Best,
On Tue, Mar 27, 2012 at 05:35:46PM -0400, seth vidal wrote:
On Tue, 27 Mar 2012 17:33:26 -0400 Konstantin Ryabitsev icon@fedoraproject.org wrote:
On Tue, 2012-03-27 at 17:17 -0400, seth vidal wrote:
And that is the more or less it - does anyone have any suggestions/thoughts?
You don't have to limit yourself to picking between user_u or guest_u. You can create another role, such as "fedorauser_u" that is basically guest_u, except you can then add specific policies via SELinux roles, such as:
irc_role(fedorauser_t, fedorauser_r)
Which should let them run an IRC client such as irsii.
On the other hand, just setting user_u is a good start and a lot less work.
Except it is more or less where we are now.
ie: user can run stuff but they cannot put any exec or suid files in any place they can write.
The debate is not about whether or not to enable this - it is about whether we need to allow network connections at all.
Allowing irc out or ssh tunnels is not significant more safety over just allowing general network communication, afaict.
I do find it useful to be able to ssh files from fedorapeople to other hosts at times (if I've uploaded them there at one point and then later realize I need them somewhere else as well).
Can't think of anything else where I need to initiate a network connection from fedorapeople.org
-Toshio
We do have:
https://fedorahosted.org/fedora-infrastructure/ticket/2586
that might be related.
I guess I'd lean toward user_t.
Note that folks who need to sudo need to still be unconfined right?
kevin
On Tue, 2012-03-27 at 17:28 -0600, Kevin Fenzi wrote:
Note that folks who need to sudo need to still be unconfined right?
No, you want them to be staff_u and add the following to your sudoers:
%wheel ALL=(ALL) TYPE=unconfined_t ROLE=unconfined_r ALL
This will transition to unconfined upon sudo.
BTW, I just found out that guest_u (and, by extension, my testguest_u) still allows sshd forwarding -- I guess it's hard to restrict that on the SELinux level. It can be disallowed in sshd config, though, including by group:
AllowTcpForwarding no Match Group wheel AllowTcpForwarding yes
Best,
infrastructure@lists.fedoraproject.org
-
Kevin Fenzi -
Konstantin Ryabitsev -
Seth Vidal -
Toshio Kuratomi