Re: [Freeipa-users] issues with nfs4 privileges.

2014-06-20 Thread Simo Sorce
On Fri, 2014-06-20 at 19:51 +0200, Rob Verduijn wrote:
> Considering the root immplications.
> 
> Handing out root to all nfs clients is indeed something that is undesirable.
> However personally I believe manually creating homedirs to be a
> procedure from the previous millenium.
> 
> Can I get freeipa to do this automatically the right way ? (respecting 
> security)

Not yet, because it is complicated, the problem is that the FreeIPA
server doesn't necessarily know "where" the home directories are.
We assume the user want's to provide them from a dedicated NAS or other
NFS Server.

We are tracking the desire to perform operations (like home directory
creation) when a user is created here:
https://fedorahosted.org/freeipa/ticket/2156

In the meanwhile I can suggest using some script in a cronjob on the NFS
Server that fetches the users list from ldap and proceed to create a
home directory from the homeDirectory attribute, if it is missing.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project


Re: [Freeipa-users] issues with nfs4 privileges.

2014-06-20 Thread Rob Verduijn
Considering the root immplications.

Handing out root to all nfs clients is indeed something that is undesirable.
However personally I believe manually creating homedirs to be a
procedure from the previous millenium.

Can I get freeipa to do this automatically the right way ? (respecting security)

Rob

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project


Re: [Freeipa-users] issues with nfs4 privileges.

2014-06-20 Thread Rob Verduijn
Hi,

I have not touched pulse audio configuration, it's set to default, I
can see in the logs the pulseaudio daemon assumes the user id.
rtkit-daemon[697]: Successfully made thread 3299 of process 3299
(/usr/bin/pulseaudio) owned by '4701' high priority at nice level
-11.
rtkit-daemon[697]: Supervising 5 threads of 2 processes of 2 users.
pulseaudio[3299]: [pulseaudio] core-util.c: Failed to create secure
directory (/home/rob/.config/pulse): Permission denied

The directory already exists, I tried removing it, which did not help.

Rob

2014-06-20 19:14 GMT+02:00 Simo Sorce :
> On Fri, 2014-06-20 at 18:57 +0200, Rob Verduijn wrote:
>> Hi Simo,
>>
>> Thanx for the quick answer, i will consider the root implications.
>> However, what about pulse audio not working ?
>> The logs complain about that one not beeing able to write in home as well.
>
> Is it running as the "pulse" user ?
> If so it would be the same issue, but I thought pulseaudio runs as the
> user by default, have you changed its configuration to run one instance
> per system by chance ?
>
> Simo.
>
> --
> Simo Sorce * Red Hat, Inc * New York
>

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project


Re: [Freeipa-users] issues with nfs4 privileges.

2014-06-20 Thread Simo Sorce
On Fri, 2014-06-20 at 18:57 +0200, Rob Verduijn wrote:
> Hi Simo,
> 
> Thanx for the quick answer, i will consider the root implications.
> However, what about pulse audio not working ?
> The logs complain about that one not beeing able to write in home as well.

Is it running as the "pulse" user ?
If so it would be the same issue, but I thought pulseaudio runs as the
user by default, have you changed its configuration to run one instance
per system by chance ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project


Re: [Freeipa-users] issues with nfs4 privileges.

2014-06-20 Thread Rob Verduijn
Hi Simo,

Thanx for the quick answer, i will consider the root implications.
However, what about pulse audio not working ?
The logs complain about that one not beeing able to write in home as well.

Rob

2014-06-20 18:27 GMT+02:00 Simo Sorce :
> On Fri, 2014-06-20 at 18:02 +0200, Rob Verduijn wrote:
>> Hello,
>>
>> I'm a bit at loss with my freeipa kerberized nfs4 shares.
>>
>> the nfs4 shares mount fine and users can read and write their files.
>> However pulse audio does not work properly, and some programs fail to start.
>> When logging in with a local account using a local homedrive
>> pulseaudio works, and the programs also work.
>> Also oddjob is not capable of creating a home dir for a new user.
>>
>> root is not allowed to write in the home mount on the client (mkdir
>> test and touch test get a Permission denied)
>>
>> I don't think its selinux, because setenforce 0 on the nfs-server and
>> setenforce 0 on the nfs client did not help.
>
> Indeed it is not selinux nor anything client related, when you use
> kerberized NFSv4 *all* accesses including root must be authenticated.
>
> When your "local" root user tries to access the mount point, either it
> cannot authenticate or it uses the system keytab to authenticate, in
> both cases, w/o further configuration on the server these accesses are
> mapped to the nobody user or refused outright.
>
> If you really want to trust *every* client to have full *root* access on
> your server then you need to make sure the client is using the host
> keytab when acting as root (default unless you pass -n to rpc.gssd) then
> you need to map explicitly the client's hosts keys to the root account
> on the server.
> add:
>  host/client.host.name@YOUR.REALM = root
> in the [static] section of idmapd.conf
>
> See idmapd.conf(5) for details.
>
>> freeipa policies seem to be working fine, sudo rules are applied the
>> way I expect them.
>> Logging in on all the machines works, automounting works like a charm,
>> except for the situations described above.
>>
>> server details are below
>>
>> Anybody who can tell me what I've missed ?
>
> What you've missed is simply that clients are not allowed to act as root
> on NFS mounts by default, it's a security issue, because a compromised
> client can then do what it want's with all NFS shared data regardless of
> user permissions.
>
> HTH,
> Simo.
>
> --
> Simo Sorce * Red Hat, Inc * New York
>

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project


Re: [Freeipa-users] issues with nfs4 privileges.

2014-06-20 Thread Simo Sorce
On Fri, 2014-06-20 at 18:02 +0200, Rob Verduijn wrote:
> Hello,
> 
> I'm a bit at loss with my freeipa kerberized nfs4 shares.
> 
> the nfs4 shares mount fine and users can read and write their files.
> However pulse audio does not work properly, and some programs fail to start.
> When logging in with a local account using a local homedrive
> pulseaudio works, and the programs also work.
> Also oddjob is not capable of creating a home dir for a new user.
> 
> root is not allowed to write in the home mount on the client (mkdir
> test and touch test get a Permission denied)
> 
> I don't think its selinux, because setenforce 0 on the nfs-server and
> setenforce 0 on the nfs client did not help.

Indeed it is not selinux nor anything client related, when you use
kerberized NFSv4 *all* accesses including root must be authenticated.

When your "local" root user tries to access the mount point, either it
cannot authenticate or it uses the system keytab to authenticate, in
both cases, w/o further configuration on the server these accesses are
mapped to the nobody user or refused outright.

If you really want to trust *every* client to have full *root* access on
your server then you need to make sure the client is using the host
keytab when acting as root (default unless you pass -n to rpc.gssd) then
you need to map explicitly the client's hosts keys to the root account
on the server.
add:
 host/client.host.name@YOUR.REALM = root
in the [static] section of idmapd.conf

See idmapd.conf(5) for details.

> freeipa policies seem to be working fine, sudo rules are applied the
> way I expect them.
> Logging in on all the machines works, automounting works like a charm,
> except for the situations described above.
> 
> server details are below
> 
> Anybody who can tell me what I've missed ?

What you've missed is simply that clients are not allowed to act as root
on NFS mounts by default, it's a security issue, because a compromised
client can then do what it want's with all NFS shared data regardless of
user permissions.

HTH,
Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project


[Freeipa-users] issues with nfs4 privileges.

2014-06-20 Thread Rob Verduijn
Hello,

I'm a bit at loss with my freeipa kerberized nfs4 shares.

the nfs4 shares mount fine and users can read and write their files.
However pulse audio does not work properly, and some programs fail to start.
When logging in with a local account using a local homedrive
pulseaudio works, and the programs also work.
Also oddjob is not capable of creating a home dir for a new user.

root is not allowed to write in the home mount on the client (mkdir
test and touch test get a Permission denied)

I don't think its selinux, because setenforce 0 on the nfs-server and
setenforce 0 on the nfs client did not help.

freeipa policies seem to be working fine, sudo rules are applied the
way I expect them.
Logging in on all the machines works, automounting works like a charm,
except for the situations described above.

server details are below

Anybody who can tell me what I've missed ?
Rob

the freeipa server is a dedicated fedora20 x86_64 machine with the
latest updates applied

the nfs-server is a fedora20 x86_64 machine with the latest updates applied

these booleans have been applied on the nfs server
nfs_export_all_ro --> on
nfs_export_all_rw --> on

The exports are :
/exports *(rw,no_root_squash,crossmnt,fsid=0,sec=krb5p)
/exports/homes *(rw,no_root_squash,no_subtree_check,sec=krb5p)

/exports/homes is a bind mount from :
/data3/homes

selinux contexts of the dirs:
ls -dalsZ /data3/homes
drwxr-xr-x. root root system_u:object_r:user_home_t:s0 /data3/homes
ls -dalsZ /exports/homes
drwxr-xr-x. root root system_u:object_r:user_home_t:s0 /exports/homes

/exportes/homes is automounted by systemd using this unit file:
cat /etc/systemd/system/exports-homes.automount
[Unit]
Description=/exports/homes Directory Automount Point
Wants=network.target statd.service
After=network.target statd.service
[Automount]
Where=/exports/homes

   [Install]
WantedBy=multi-user.target

and the matching unit mount:
cat /etc/systemd/system/exports-homes.mount
[Unit]
Description=Exports Homes Directory
Wants=network.target statd.service
After=network.target statd.service
[Mount]
What=/data3/homes
Where=/exports/homes
Type=none
Options=bind
DirectoryMode=0755

the nfs client is a fedora20 x86_64 machine with al the latest patches applied
This boolean has been set:
use_nfs_home_dirs --> on

ls -dalsZ /home/
drwxr-xr-x. root root system_u:object_r:user_home_t:s0 /home/

the home folder is automounted by systemd using this unit file :
cat /etc/systemd/system/home.automount
[Unit]
Description=Home Directory Automount Point
Wants=network.target statd.service
After=network.target statd.service
[Automount]
Where=/home
[Install]
WantedBy=multi-user.target

and the matching unit mount
cat /etc/systemd/system/home.mount
[Unit]
Description=Home Directory
Wants=network.target statd.service
After=network.target statd.service
[Mount]
What=172.16.1.1:/homes
Where=/home
Type=nfs4
Options=timeo=14,noatime,timeo=14,soft,sec=krb5p,context=system_u:object_r:user_home_t:s0
DirectoryMode=0750

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project