Re: [Freeipa-users] apache kerberized nfs4 /var/www/html access denied for apache user
On 09/20/2014 05:19 PM, Simo Sorce wrote: On Sat, 20 Sep 2014 19:44:28 +0200 Rob Verduijn rob.verdu...@gmail.com wrote: Hi again, Thank you for the quick response. I've removed the credstore entries that are not necessary for the nfs access. Now the users no longer go through gssproxy, but apache does. I've googled around quite a bit and and it seems that your presentation on youtube and the gssproxy page together with a bit on the fedora site are about it concerning documentation. We do not have a lot of docs yet, indeed. Is there any chance we can publish this setup somewhere as a HOWTO? May be on GSS proxy or IPA wiki? That would help others coming after you. If you have a fedora account you can add content to FreeIPA wiki. The below gssproxy.conf works fine for apache accessing a kerberized nfs share without having to authenticate against ipa. If I were to create another share for say an tftp directory do I need to create another entry like the one below or can I simply say : euid = 48,1,2,3,4 Nope, euid is singlevalued. Should we open RFE for it? ding-libs can return you a list of numbers. Or maybe this if you won't mind that any service with a keytab gets nfs access. euid = %U Setting %U in euid does not work, that's why we have allow_any_uid. Thanx for the quick help. Glad you got it working to your liking, and feel free to ask questions directly on the gss-proxy mailing list if you want. Btw in the conf below you can also remove completely the allow_any_uid (no is the default) and the trusted options (you should not really trust apache to impersonate any user, w/o trusted it will just be itself). Simo. [gssproxy] [service/nfs-client] mechs = krb5 cred_store = client_keytab:/etc/gssproxy/%U.keytab cred_usage = initiate allow_any_uid = no trusted = yes euid = 48 2014-09-20 18:15 GMT+02:00 Simo Sorce s...@redhat.com: On Sat, 20 Sep 2014 16:53:48 +0200 Rob Verduijn rob.verdu...@gmail.com wrote: Hello all, I've managed to get the gssproxy to work on my installation. I can now mount my apache document root using sec=krb5p and apache automagically mounts the share when needed. However I noticed that now all nfs credentials are going through gssproxy. Is there a way to disable this for regular users (or only enable it for apache) Below is the gssproxy.conf I used I assume you mean that gssproxy is used for all users when rpc.gssd is used ? You cannot pick and choose this way, but gss-proxy can be configured to user regular user's caches so that it preserve proper authorization for access. Cheers Rob [gssproxy] [service/nfs-client] mechs = krb5 cred_store = keytab:/etc/krb5.keytab cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U cred_store = client_keytab:/etc/gssproxy/%U.keytab cred_usage = initiate allow_any_uid = yes trusted = yes euid = 0 You do not need allow_any_uid in your case as rpc.gssd always runs as root. You can also remove the keytab:/etc/krb5.keytab option as you are only going to initiate with explicit client keytabs. If you only have the apache keytab in /etc/gssproxy then for any other user will fall back to local resolution. You may also experiment with setting ccache to the default for your system so that gss-proxy can find actual user's ccaches, though that may comport some minor risk and will force you to run gss-proxy as root. HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- 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] apache kerberized nfs4 /var/www/html access denied for apache user
On Mon, 22 Sep 2014 15:09:42 -0400 Dmitri Pal d...@redhat.com wrote: On 09/20/2014 05:19 PM, Simo Sorce wrote: On Sat, 20 Sep 2014 19:44:28 +0200 Rob Verduijn rob.verdu...@gmail.com wrote: Hi again, Thank you for the quick response. I've removed the credstore entries that are not necessary for the nfs access. Now the users no longer go through gssproxy, but apache does. I've googled around quite a bit and and it seems that your presentation on youtube and the gssproxy page together with a bit on the fedora site are about it concerning documentation. We do not have a lot of docs yet, indeed. Is there any chance we can publish this setup somewhere as a HOWTO? May be on GSS proxy or IPA wiki? That would help others coming after you. If you have a fedora account you can add content to FreeIPA wiki. With a Fedora account you can also write to the GSS-Proxy wiki which may be more appropriate. The below gssproxy.conf works fine for apache accessing a kerberized nfs share without having to authenticate against ipa. If I were to create another share for say an tftp directory do I need to create another entry like the one below or can I simply say : euid = 48,1,2,3,4 Nope, euid is singlevalued. Should we open RFE for it? ding-libs can return you a list of numbers. No, it rarely if ever would make sense to do so, And we want to move the conf to have multiple conf snippets instead of a single file, in that case you'll want to have multiple snippets one per user. 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] apache kerberized nfs4 /var/www/html access denied for apache user
Hello all, I've managed to get the gssproxy to work on my installation. I can now mount my apache document root using sec=krb5p and apache automagically mounts the share when needed. However I noticed that now all nfs credentials are going through gssproxy. Is there a way to disable this for regular users (or only enable it for apache) Below is the gssproxy.conf I used Cheers Rob [gssproxy] [service/nfs-client] mechs = krb5 cred_store = keytab:/etc/krb5.keytab cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U cred_store = client_keytab:/etc/gssproxy/%U.keytab cred_usage = initiate allow_any_uid = yes trusted = yes euid = 0 2014-09-17 9:15 GMT+02:00 Rob Verduijn rob.verdu...@gmail.com: 2014-09-16 20:57 GMT+02:00 Nordgren, Bryce L -FS bnordg...@fs.fed.us: Also opened https://fedorahosted.org/freeipa/ticket/4544 Tried to summarize this thread on that ticket. Back to the OP's concern, whenever I use NFS as a documentroot for apache (even a WebDAV server), I make a separate mountpoint, fall back to sec=sys, set all-squash, and specify the webserver's IP. It's not like individual user accounts need a presence on the filesystem. Do you need encryption for your application or is apache just going to spray the content out across the commodity internet via un-encrypted http? Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. -- 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 Hello, I've already implemented the share as 1.2.3.4(ro,sync,all-squash,sec=sys) It's not sensitive data and it's also internal, so it will do fine for now as a workaround. But there is going to be a situation that apache requires access to a document root containing sensitive data, in that case I would prefer a more secure method. I've been reading up a little on the gss-proxy, which would be the prefered way on the obtaining of the credentials from a keytab. Have gss-proxy do it or have gss-proxy use s4u2proxy to fetch the keytab ? (which might also solve some of my ssh anoyances but that's a bit off topic) Rob Verduijn -- 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] apache kerberized nfs4 /var/www/html access denied for apache user
On Sat, 20 Sep 2014 16:53:48 +0200 Rob Verduijn rob.verdu...@gmail.com wrote: Hello all, I've managed to get the gssproxy to work on my installation. I can now mount my apache document root using sec=krb5p and apache automagically mounts the share when needed. However I noticed that now all nfs credentials are going through gssproxy. Is there a way to disable this for regular users (or only enable it for apache) Below is the gssproxy.conf I used I assume you mean that gssproxy is used for all users when rpc.gssd is used ? You cannot pick and choose this way, but gss-proxy can be configured to user regular user's caches so that it preserve proper authorization for access. Cheers Rob [gssproxy] [service/nfs-client] mechs = krb5 cred_store = keytab:/etc/krb5.keytab cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U cred_store = client_keytab:/etc/gssproxy/%U.keytab cred_usage = initiate allow_any_uid = yes trusted = yes euid = 0 You do not need allow_any_uid in your case as rpc.gssd always runs as root. You can also remove the keytab:/etc/krb5.keytab option as you are only going to initiate with explicit client keytabs. If you only have the apache keytab in /etc/gssproxy then for any other user will fall back to local resolution. You may also experiment with setting ccache to the default for your system so that gss-proxy can find actual user's ccaches, though that may comport some minor risk and will force you to run gss-proxy as root. 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] apache kerberized nfs4 /var/www/html access denied for apache user
On Saturday, September 20, 2014 12:15:04 PM Simo Sorce wrote: [service/nfs-client] mechs = krb5 cred_store = keytab:/etc/krb5.keytab cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U cred_store = client_keytab:/etc/gssproxy/%U.keytab cred_usage = initiate allow_any_uid = yes trusted = yes euid = 0 You do not need allow_any_uid in your case as rpc.gssd always runs as root. You can also remove the keytab:/etc/krb5.keytab option as you are only going to initiate with explicit client keytabs. If you only have the apache keytab in /etc/gssproxy then for any other user will fall back to local resolution. You may also experiment with setting ccache to the default for your system so that gss-proxy can find actual user's ccaches, though that may comport some minor risk and will force you to run gss-proxy as root. Simo, Rob's [service/nfs-client] configuration looks identical to mine, which appears to be the default, at least in Fedora 20: https://git.fedorahosted.org/cgit/gss-proxy.git/tree/proxy/examples/gssproxy.conf.in -- Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E signature.asc Description: This is a digitally signed message part. -- 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] apache kerberized nfs4 /var/www/html access denied for apache user
Hi again, Thank you for the quick response. I've removed the credstore entries that are not necessary for the nfs access. Now the users no longer go through gssproxy, but apache does. I've googled around quite a bit and and it seems that your presentation on youtube and the gssproxy page together with a bit on the fedora site are about it concerning documentation. The below gssproxy.conf works fine for apache accessing a kerberized nfs share without having to authenticate against ipa. If I were to create another share for say an tftp directory do I need to create another entry like the one below or can I simply say : euid = 48,1,2,3,4 Or maybe this if you won't mind that any service with a keytab gets nfs access. euid = %U Thanx for the quick help. [gssproxy] [service/nfs-client] mechs = krb5 cred_store = client_keytab:/etc/gssproxy/%U.keytab cred_usage = initiate allow_any_uid = no trusted = yes euid = 48 2014-09-20 18:15 GMT+02:00 Simo Sorce s...@redhat.com: On Sat, 20 Sep 2014 16:53:48 +0200 Rob Verduijn rob.verdu...@gmail.com wrote: Hello all, I've managed to get the gssproxy to work on my installation. I can now mount my apache document root using sec=krb5p and apache automagically mounts the share when needed. However I noticed that now all nfs credentials are going through gssproxy. Is there a way to disable this for regular users (or only enable it for apache) Below is the gssproxy.conf I used I assume you mean that gssproxy is used for all users when rpc.gssd is used ? You cannot pick and choose this way, but gss-proxy can be configured to user regular user's caches so that it preserve proper authorization for access. Cheers Rob [gssproxy] [service/nfs-client] mechs = krb5 cred_store = keytab:/etc/krb5.keytab cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U cred_store = client_keytab:/etc/gssproxy/%U.keytab cred_usage = initiate allow_any_uid = yes trusted = yes euid = 0 You do not need allow_any_uid in your case as rpc.gssd always runs as root. You can also remove the keytab:/etc/krb5.keytab option as you are only going to initiate with explicit client keytabs. If you only have the apache keytab in /etc/gssproxy then for any other user will fall back to local resolution. You may also experiment with setting ccache to the default for your system so that gss-proxy can find actual user's ccaches, though that may comport some minor risk and will force you to run gss-proxy as root. 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] apache kerberized nfs4 /var/www/html access denied for apache user
On Sat, 20 Sep 2014 11:38:16 -0500 Anthony Messina amess...@messinet.com wrote: On Saturday, September 20, 2014 12:15:04 PM Simo Sorce wrote: [service/nfs-client] mechs = krb5 cred_store = keytab:/etc/krb5.keytab cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U cred_store = client_keytab:/etc/gssproxy/%U.keytab cred_usage = initiate allow_any_uid = yes trusted = yes euid = 0 You do not need allow_any_uid in your case as rpc.gssd always runs as root. You can also remove the keytab:/etc/krb5.keytab option as you are only going to initiate with explicit client keytabs. If you only have the apache keytab in /etc/gssproxy then for any other user will fall back to local resolution. You may also experiment with setting ccache to the default for your system so that gss-proxy can find actual user's ccaches, though that may comport some minor risk and will force you to run gss-proxy as root. Simo, Rob's [service/nfs-client] configuration looks identical to mine, which appears to be the default, at least in Fedora 20: https://git.fedorahosted.org/cgit/gss-proxy.git/tree/proxy/examples/gssproxy.conf.in Oh it is and I forgot why we put allow_any_uid in, it's because now rpc.gssd drops privileges before checking ccaches ... doh, I had forgotten. I wonder if we should remove the keytab from the default configuration though ... 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] apache kerberized nfs4 /var/www/html access denied for apache user
On Sat, 20 Sep 2014 19:44:28 +0200 Rob Verduijn rob.verdu...@gmail.com wrote: Hi again, Thank you for the quick response. I've removed the credstore entries that are not necessary for the nfs access. Now the users no longer go through gssproxy, but apache does. I've googled around quite a bit and and it seems that your presentation on youtube and the gssproxy page together with a bit on the fedora site are about it concerning documentation. We do not have a lot of docs yet, indeed. The below gssproxy.conf works fine for apache accessing a kerberized nfs share without having to authenticate against ipa. If I were to create another share for say an tftp directory do I need to create another entry like the one below or can I simply say : euid = 48,1,2,3,4 Nope, euid is singlevalued. Or maybe this if you won't mind that any service with a keytab gets nfs access. euid = %U Setting %U in euid does not work, that's why we have allow_any_uid. Thanx for the quick help. Glad you got it working to your liking, and feel free to ask questions directly on the gss-proxy mailing list if you want. Btw in the conf below you can also remove completely the allow_any_uid (no is the default) and the trusted options (you should not really trust apache to impersonate any user, w/o trusted it will just be itself). Simo. [gssproxy] [service/nfs-client] mechs = krb5 cred_store = client_keytab:/etc/gssproxy/%U.keytab cred_usage = initiate allow_any_uid = no trusted = yes euid = 48 2014-09-20 18:15 GMT+02:00 Simo Sorce s...@redhat.com: On Sat, 20 Sep 2014 16:53:48 +0200 Rob Verduijn rob.verdu...@gmail.com wrote: Hello all, I've managed to get the gssproxy to work on my installation. I can now mount my apache document root using sec=krb5p and apache automagically mounts the share when needed. However I noticed that now all nfs credentials are going through gssproxy. Is there a way to disable this for regular users (or only enable it for apache) Below is the gssproxy.conf I used I assume you mean that gssproxy is used for all users when rpc.gssd is used ? You cannot pick and choose this way, but gss-proxy can be configured to user regular user's caches so that it preserve proper authorization for access. Cheers Rob [gssproxy] [service/nfs-client] mechs = krb5 cred_store = keytab:/etc/krb5.keytab cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U cred_store = client_keytab:/etc/gssproxy/%U.keytab cred_usage = initiate allow_any_uid = yes trusted = yes euid = 0 You do not need allow_any_uid in your case as rpc.gssd always runs as root. You can also remove the keytab:/etc/krb5.keytab option as you are only going to initiate with explicit client keytabs. If you only have the apache keytab in /etc/gssproxy then for any other user will fall back to local resolution. You may also experiment with setting ccache to the default for your system so that gss-proxy can find actual user's ccaches, though that may comport some minor risk and will force you to run gss-proxy as root. HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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] apache kerberized nfs4 /var/www/html access denied for apache user
2014-09-16 20:57 GMT+02:00 Nordgren, Bryce L -FS bnordg...@fs.fed.us: Also opened https://fedorahosted.org/freeipa/ticket/4544 Tried to summarize this thread on that ticket. Back to the OP's concern, whenever I use NFS as a documentroot for apache (even a WebDAV server), I make a separate mountpoint, fall back to sec=sys, set all-squash, and specify the webserver's IP. It's not like individual user accounts need a presence on the filesystem. Do you need encryption for your application or is apache just going to spray the content out across the commodity internet via un-encrypted http? Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. -- 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 Hello, I've already implemented the share as 1.2.3.4(ro,sync,all-squash,sec=sys) It's not sensitive data and it's also internal, so it will do fine for now as a workaround. But there is going to be a situation that apache requires access to a document root containing sensitive data, in that case I would prefer a more secure method. I've been reading up a little on the gss-proxy, which would be the prefered way on the obtaining of the credentials from a keytab. Have gss-proxy do it or have gss-proxy use s4u2proxy to fetch the keytab ? (which might also solve some of my ssh anoyances but that's a bit off topic) Rob Verduijn -- 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] apache kerberized nfs4 /var/www/html access denied for apache user
Hello, I've got a webserver whose default export is on a kerberized nfs4 export. The export works fine for regular ipa users However the apache user is not allowed to read anything from the export. What would be the best practice to allow the apache user access to the nfs4 export without switching to sec=sys ? Cheers 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] apache kerberized nfs4 /var/www/html access denied for apache user
Hi Rob, How does the NFS server map the apache user to “something” it recognizes? I would suggest that the easiest solution may be to use an IPA account called “apache”, so that the mappings would just work, but currently I’m having trouble running a service as a domain user via systemd. (https://lists.fedorahosted.org/pipermail/sssd-users/2014-September/002194.html) Beyond that, for kerberized NFS (local or domain user), you’ll need something to keep a fresh ticket on hand, so you may end up running something like k5start, and setting KRB5CCNAME in the environment where you’re running apache. Bryce From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Rob Verduijn Sent: Monday, September 15, 2014 9:17 AM To: freeipa-users@redhat.com Subject: [Freeipa-users] apache kerberized nfs4 /var/www/html access denied for apache user Hello, I've got a webserver whose default export is on a kerberized nfs4 export. The export works fine for regular ipa users However the apache user is not allowed to read anything from the export. What would be the best practice to allow the apache user access to the nfs4 export without switching to sec=sys ? Cheers Rob This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. -- 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] apache kerberized nfs4 /var/www/html access denied for apache user
On Monday, September 15, 2014 06:10:13 PM Nordgren, Bryce L -FS wrote: How does the NFS server map the apache user to “something” it recognizes? I would suggest that the easiest solution may be to use an IPA account called “apache”, so that the mappings would just work, but currently I’m having trouble running a service as a domain user via systemd. (https://lists.fedorahosted.org/pipermail/sssd-users/2014-September/002194. html) Regarding your thread on the sssd-users list, this issue has to do with systemd not looking up non-local users (via nss/sssd) as these accounts are not usually available at boot. I had tried something similar using k5start (prior to using gssproxy) and found this out: https://bugzilla.redhat.com/show_bug.cgi?id=915912 Beyond that, for kerberized NFS (local or domain user), you’ll need something to keep a fresh ticket on hand, so you may end up running something like k5start, and setting KRB5CCNAME in the environment where you’re running apache. I now use gssproxy for this purpose -- maintaining NFS/KRB5 credentials for the apache user. But I can tell you that I haven't yet figured out what I need to do to have FreeIPA issue Kerberos credentials for the apache user, while restricting the apache user in FreeIPA, based on the security concerns mentioned by John Dennis in the following email: https://www.redhat.com/archives/freeipa-users/2013-February/msg00268.html. Not trying to hijack the thread, but it would be helpful to have some instruction on: What is the FreeIPA-recommended way to enable Kerberos functionality for a system account user, while restricting that system-account user? The apache user being one that seems to be brought up frequently. -A -- Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E signature.asc Description: This is a digitally signed message part. -- 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
