Re: [Freeipa-users] local root can su to any IPA user
Caching credentials is disabled by default[1]. Even when credential caching is enabled, the cache is only ever readable by root, the hashes are *never* exposed to the system. FYI, the hash is a salted sha512. Ah. Much better. What leads you to believe the cached credentials can be retrieved? --- RedHat sssd documentation from [2] --- Using a single user account. Remote users frequently have two (or even more) user accounts, such as one for their local system and one for the organizational system. This is necessary to connect to a virtual private network (VPN). Because SSSD supports caching and offline authentication, remote users can connect to network resources simply by authenticating to their local machine and then SSSD maintains their network credentials. ---End RedHat sssd documentation from [2] --- Presumably VPN does not accept a hash. Even if it does, gaining access to the hash gains you admission to the network as someone else. [2] https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/SSSD.htm 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. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] local root can su to any IPA user
On Fri, 2014-02-28 at 14:42 +, Nordgren, Bryce L -FS wrote: Caching credentials is disabled by default[1]. Even when credential caching is enabled, the cache is only ever readable by root, the hashes are *never* exposed to the system. FYI, the hash is a salted sha512. Ah. Much better. What leads you to believe the cached credentials can be retrieved? --- RedHat sssd documentation from [2] --- Using a single user account. Remote users frequently have two (or even more) user accounts, such as one for their local system and one for the organizational system. This is necessary to connect to a virtual private network (VPN). Because SSSD supports caching and offline authentication, remote users can connect to network resources simply by authenticating to their local machine and then SSSD maintains their network credentials. ---End RedHat sssd documentation from [2] --- Presumably VPN does not accept a hash. Even if it does, gaining access to the hash gains you admission to the network as someone else. [2] https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/SSSD.htm Offline password caching is also optional and a different method. In this case the actual password is maintained in the kernel keyring in locked memory until the machine goes online and can acquire a TGT. On success it is deleted. however it doesn't really matter from an evil-root scenario, because evil-root will have already snatched the password from the PAM stack at authentication time. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] local root can su to any IPA user
On Fri, Feb 28, 2014 at 09:56:26AM -0500, Simo Sorce wrote: On Fri, 2014-02-28 at 14:42 +, Nordgren, Bryce L -FS wrote: Caching credentials is disabled by default[1]. Even when credential caching is enabled, the cache is only ever readable by root, the hashes are *never* exposed to the system. FYI, the hash is a salted sha512. Ah. Much better. What leads you to believe the cached credentials can be retrieved? --- RedHat sssd documentation from [2] --- Using a single user account. Remote users frequently have two (or even more) user accounts, such as one for their local system and one for the organizational system. This is necessary to connect to a virtual private network (VPN). Because SSSD supports caching and offline authentication, remote users can connect to network resources simply by authenticating to their local machine and then SSSD maintains their network credentials. ---End RedHat sssd documentation from [2] --- Presumably VPN does not accept a hash. Even if it does, gaining access to the hash gains you admission to the network as someone else. [2] https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/SSSD.htm Offline password caching is also optional and a different method. In this case the actual password is maintained in the kernel keyring in locked memory until the machine goes online and can acquire a TGT. On success it is deleted. however it doesn't really matter from an evil-root scenario, because evil-root will have already snatched the password from the PAM stack at authentication time. Simo. Right, just for completeness, the option that Simo describes is called krb5_store_password_if_offline. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] local root can su to any IPA user
Offline password caching is also optional and a different method. In this case the actual password is maintained in the kernel keyring in locked memory until the machine goes online and can acquire a TGT. On success it is deleted. however it doesn't really matter from an evil-root scenario, because evil-root will have already snatched the password from the PAM stack at authentication time. Ah. My evil root scenario was that my AS exchange happened on my trusted machine and I used SSO to sign in to Evil root's machine. No password in Evil's pam stack. Evil can log into an Evil-compromised machine all he wants. Can't steal a password from yourself. Please shoot holes in this design for me: :) A domain uses Kerberos for authentication. The domain does not allow LDAP or other forms of authentication. A domain has trusted, domain-administrated machines for initial sign on. Users are not given root access on these machines. Alternatively, users who have been given root access to a machine can initiate an AS exchange from machines they control, but others cannot and/or are strongly discouraged from doing so. Hence, a user can be granted control over their own workstation/laptop. Users are given permissions on machines as needed to configure whatever it is that they need to do. Say there is some sort of project with specialized requirements which affects ~10-50 participants or so. Someone in the project stands up a machine to address the project's needs, but this person is not part of the Organization, so he could be Evil. Users would be expected to perform their initial sign on using their own workstation/terminal, then connect to the project resource. Ideally, the project resource is a website of some type, so only a Kerberos service ticket is needed. In the case that project members need command line access, but no access to domain-wide services (like NFS server), they can just get a service ticket for host/evil.example@example.org. So far, Evil is boxed in. Evil has not been given credentials which allow him to impersonate another user to the domain. Evil's box is a black hole. Identities go in, but they can't get out. A problem occurs when users need to access domain-wide services from Evil's machine. The user (Innocent) can forward their TGT to Evil's machine, giving Evil full use of Innocent's identity, or Innocent can use their own, trusted workstation to individually request proxy tickets for the services Innocent intends to access. Evil can now impersonate Innocent. In the case where Evil received proxy tickets, it can only impersonate Innocent to specific services on specific hosts. In the case where Evil received a TGT, Evil can impersonate innocent at will to any domain service. This suggests that it should be a security requirement for non-organization-wide projects to provide their own services. This permits encouraging/mandating the use of service tickets with project resources. For instance, if the project needs file storage, they should provide file storage. Alternatively, if the organization wishes to provide storage, they may want to allocate servers (and Kerberos principals) individually for each project. This seems to me to be a way to compartmentalize groups of cooperating users in a way that tends to prevent Evil in one group from spreading to another group, while allowing users to leverage the organization's identity store...It seems to me that this is even more effective at stopping the spread of Evil than establishing hierarchical cross-realm trusts underneath the main organization... Am I overlooking something, or is this likely to be an effective means of delegating small project support while sideboarding potential Evil? 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. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] local root can su to any IPA user
Some further reading material about operating in a security model where you accept that things are already compromised: * CISecurity did a good job on the Kerberos benchmark that was written: http://benchmarks.cisecurity.org/downloads/show-single/index.cfm?file=mitkerberos110.100 * Two Factor should be employed on any system you consider critical: As far as Identities go, The Password is Dead... YubiKey is a pretty good, low overhead starting point, http://wiki.yubico.com/wiki/index.php/Main_Page * Long Live POSIX, the owner,group,everyone model has been broken for quite sometime. I suggest checking out Capsicum in addition to any further reading about trusted computing or SElinux, etc. http://www.cl.cam.ac.uk/research/security/capsicum/ https://github.com/google/capsicum-linux On Feb 28, 2014, at 9:27 AM, Nordgren, Bryce L -FS bnordg...@fs.fed.us wrote: Offline password caching is also optional and a different method. In this case the actual password is maintained in the kernel keyring in locked memory until the machine goes online and can acquire a TGT. On success it is deleted. however it doesn't really matter from an evil-root scenario, because evil-root will have already snatched the password from the PAM stack at authentication time. Ah. My evil root scenario was that my AS exchange happened on my trusted machine and I used SSO to sign in to Evil root's machine. No password in Evil's pam stack. Evil can log into an Evil-compromised machine all he wants. Can't steal a password from yourself. Please shoot holes in this design for me: :) A domain uses Kerberos for authentication. The domain does not allow LDAP or other forms of authentication. A domain has trusted, domain-administrated machines for initial sign on. Users are not given root access on these machines. Alternatively, users who have been given root access to a machine can initiate an AS exchange from machines they control, but others cannot and/or are strongly discouraged from doing so. Hence, a user can be granted control over their own workstation/laptop. Users are given permissions on machines as needed to configure whatever it is that they need to do. Say there is some sort of project with specialized requirements which affects ~10-50 participants or so. Someone in the project stands up a machine to address the project's needs, but this person is not part of the Organization, so he could be Evil. Users would be expected to perform their initial sign on using their own workstation/terminal, then connect to the project resource. Ideally, the project resource is a website of some type, so only a Kerberos service ticket is needed. In the case that project members need command line access, but no access to domain-wide services (like NFS server), they can just get a service ticket for host/evil.example@example.org. So far, Evil is boxed in. Evil has not been given credentials which allow him to impersonate another user to the domain. Evil's box is a black hole. Identities go in, but they can't get out. A problem occurs when users need to access domain-wide services from Evil's machine. The user (Innocent) can forward their TGT to Evil's machine, giving Evil full use of Innocent's identity, or Innocent can use their own, trusted workstation to individually request proxy tickets for the services Innocent intends to access. Evil can now impersonate Innocent. In the case where Evil received proxy tickets, it can only impersonate Innocent to specific services on specific hosts. In the case where Evil received a TGT, Evil can impersonate innocent at will to any domain service. This suggests that it should be a security requirement for non-organization-wide projects to provide their own services. This permits encouraging/mandating the use of service tickets with project resources. For instance, if the project needs file storage, they should provide file storage. Alternatively, if the organization wishes to provide storage, they may want to allocate servers (and Kerberos principals) individually for each project. This seems to me to be a way to compartmentalize groups of cooperating users in a way that tends to prevent Evil in one group from spreading to another group, while allowing users to leverage the organization's identity store...It seems to me that this is even more effective at stopping the spread of Evil than establishing hierarchical cross-realm trusts underneath the main organization... Am I overlooking something, or is this likely to be an effective means of delegating small project support while sideboarding potential Evil? 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
Re: [Freeipa-users] local root can su to any IPA user
On Fri, 2014-02-28 at 17:27 +, Nordgren, Bryce L -FS wrote: Am I overlooking something, or is this likely to be an effective means of delegating small project support while sideboarding potential Evil? Well, there area always caveats, mostly that you will find exceptions you have to permit for whatever reason, so you generally need a workable exception mechanism when that happens, auditing can be a suitable mitigation factor in those cases. That said I think JR also gave excellent points. Esp wrt 2FA which, incidentally, we are almost done implementing in FreeIPA. With 2FA you substantially reduce the threat of stolen passwords, when you have to allow password login on less trusted machines, at least for human accounts. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] local root can su to any IPA user
On Wed, Feb 26, 2014 at 04:24:54PM -0500, Steve Dainard wrote: Would it not be possible for root to disable selinux enforcement? Normally yes, if you're root, you can do all kinds of stuff including appending 'selinux=0' to the kernel command line. Maybe there are better SELinux experts on the list, but if you need to partition the power of root further, maybe MLS SELinux configuration is what you need? A user could maybe even use a livecd if root couldn't be gained directly. Can you protect the bootloader with a password? btw if malicious users have physical access to the hardware, then you're in a difficult situation anyway.. I'm looking at joining workstations to an idm realm, but some users will need sudo permissions on their machines. Do they need the full sudo permissions (to become root) ? Can you just give them permissions to run specific commands (ie /sbin/service etc) ? Is there any documentation on best practices here? Has there been any further discussion on the best way to approach this problem? Thanks, *Steve Dainard * IT Infrastructure Manager Miovision http://miovision.com/ | *Rethink Traffic* *Blog http://miovision.com/blog | **LinkedIn https://www.linkedin.com/company/miovision-technologies | Twitter https://twitter.com/miovision | Facebook https://www.facebook.com/miovision* -- Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. On Fri, Nov 29, 2013 at 9:41 AM, Martin Kosek mko...@redhat.com wrote: On 11/29/2013 03:17 PM, Jakub Hrozek wrote: On Fri, Nov 29, 2013 at 03:08:44PM +0100, Fred van Zwieten wrote: Jakub, Yes, I could do this. But then the local root account cannot su to local users (without password). But that is actually a normal use-case. I just think local root should not be allowed to transition to a domain user, by default. Fred Ah, in that case I'm not sure if there's an easy solution, at least I don't know any off hand. I think Alexander is right that SELinux would be a good choice. Right. Root could uncomment the pam_rootok.so line anyway if he wanted to access other user's account again. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] local root can su to any IPA user
On Wed, Feb 26, 2014 at 04:24:54PM -0500, Steve Dainard wrote: Would it not be possible for root to disable selinux enforcement? It should also be possible to copy private keys out of ~user/.ssh and login to other machines as user, assuming no password on the ssh key pair. It's probably best to assume that all your client machines are under the control of knowledgeable, malicious admins, and to put your important information somewhere other than your client machines. The only real way to take back the night is to force your users to connect to a service you control using an authentication mechanism you control. (e.g., Kerberos service tickets: accept no substitute. :) ) Prohibiting them from making any changes makes you responsible for every last customization. Delegating frees you up, but requires trust. Probably a good rule of thumb is to be generous doling out permissions when only one person will ever use the machine. Giving someone control over someone else's workspace should require consent of the controlled. One thing that is nagging at me: I read that sssd caches your credentials in a form such that they can be retrieved and provided to your organizational system. [1] This seems like a vector for a knowledgeable, malicious admin to break out of the client machine and impersonate someone else to any domain service. Is there a safeguard against this? Bryce [1] https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/SSSD.html 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. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] local root can su to any IPA user
On 02/27/2014 04:03 PM, Nordgren, Bryce L -FS wrote: On Wed, Feb 26, 2014 at 04:24:54PM -0500, Steve Dainard wrote: Would it not be possible for root to disable selinux enforcement? It should also be possible to copy private keys out of ~user/.ssh and login to other machines as user, assuming no password on the ssh key pair. It's probably best to assume that all your client machines are under the control of knowledgeable, malicious admins, and to put your important information somewhere other than your client machines. The only real way to take back the night is to force your users to connect to a service you control using an authentication mechanism you control. (e.g., Kerberos service tickets: accept no substitute. :) ) Prohibiting them from making any changes makes you responsible for every last customization. Delegating frees you up, but requires trust. Probably a good rule of thumb is to be generous doling out permissions when only one person will ever use the machine. Giving someone control over someone else's workspace should require consent of the controlled. One thing that is nagging at me: I read that sssd caches your credentials in a form such that they can be retrieved and provided to your organizational system. [1] This seems like a vector for a knowledgeable, malicious admin to break out of the client machine and impersonate someone else to any domain service. Is there a safeguard against this? SSSD will do catching and storing password only if configured and if the system can't connect to the central server so potentially a bad root admin can configure SSSD to store passwords and then lure other users to connect to the box and while the box is not connected to the central server passwords will be local and root would be able to steal them and impersonate uses. But I would argue that in this case root can just add some other module to the pam stack that would dump passwords for any user who uses pam stack regardless whether SSSD is in the picture or not so it is not SSSD problem and I do not think it can be generally solved with the software. It is the point where you cross the line into physical security and organization's security and trust policies. Bryce [1] https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/SSSD.html 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. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] local root can su to any IPA user
But I would argue that in this case root can just add some other module to the pam stack that would dump passwords for any user who uses pam stack regardless whether SSSD is in the picture or not so it is not SSSD problem and I do not think it can be generally solved with the software. It is the point where you cross the line into physical security and organization's security and trust policies. In a Kerberos/IdM/AD environment, the password isn't available except at initial sign on. If I sign on using my machine, then ssh to user Evil's machine, the worst user Evil can do is steal my TGT, which has a much shorter life than a password. If Evil is quick, he can get at my files on the main server. But I never give my password to user Evil in this situation, and user Evil is not an admin on my box, where he can affect the pam stack. Thinking this through...This is definitely not a physical security thing: the machine was issued to user Evil and Evil must have physical access to it. These factors are not amenable to change. The problem is that risk and granting power are two sides of the same coin. The challenge is to grant useful amounts of power while mitigating risk to others. For instance: the above description suggests that one way to mitigate risk is to not delegate administrative control over machines which handle other people's passwords. Whether this is policy or just good practice is perhaps a matter of semantics. Either way: Training the users to do the initial signon on their own box will go a long way to eliminating the need for a technical control...Definitely not a software problem... 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. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] local root can su to any IPA user
On Thu, Feb 27, 2014 at 09:03:35PM +, Nordgren, Bryce L -FS wrote: On Wed, Feb 26, 2014 at 04:24:54PM -0500, Steve Dainard wrote: Would it not be possible for root to disable selinux enforcement? It should also be possible to copy private keys out of ~user/.ssh and login to other machines as user, assuming no password on the ssh key pair. It's probably best to assume that all your client machines are under the control of knowledgeable, malicious admins, and to put your important information somewhere other than your client machines. The only real way to take back the night is to force your users to connect to a service you control using an authentication mechanism you control. (e.g., Kerberos service tickets: accept no substitute. :) ) Prohibiting them from making any changes makes you responsible for every last customization. Delegating frees you up, but requires trust. Probably a good rule of thumb is to be generous doling out permissions when only one person will ever use the machine. Giving someone control over someone else's workspace should require consent of the controlled. One thing that is nagging at me: I read that sssd caches your credentials in a form such that they can be retrieved and provided to your organizational system. [1] This seems like a vector for a knowledgeable, malicious admin to break out of the client machine and impersonate someone else to any domain service. Is there a safeguard against this? Caching credentials is disabled by default[1]. Even when credential caching is enabled, the cache is only ever readable by root, the hashes are *never* exposed to the system. FYI, the hash is a salted sha512. What leads you to believe the cached credentials can be retrieved? [1] in sssd upstream. ipa-client-install enables caching credentials. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] local root can su to any IPA user
On Thu, Feb 27, 2014 at 10:36:01PM +, Nordgren, Bryce L -FS wrote: But I would argue that in this case root can just add some other module to the pam stack that would dump passwords for any user who uses pam stack regardless whether SSSD is in the picture or not so it is not SSSD problem and I do not think it can be generally solved with the software. It is the point where you cross the line into physical security and organization's security and trust policies. In a Kerberos/IdM/AD environment, the password isn't available except at initial sign on. If I sign on using my machine, then ssh to user Evil's machine, the worst user Evil can do is steal my TGT, which has a much shorter life than a password. If Evil is quick, he can get at my files on the main server. But I never give my password to user Evil in this situation, and user Evil is not an admin on my box, where he can affect the pam stack. Assuming you're using the TGT (acquired on your machine) to SSH to Evil, it's still the same case and the SSSD is not even involved. If you're typing your Kerberos password to a machine controlled by Evil, you have problems :-) But that's true with or without SSSD. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] local root can su to any IPA user
Would it not be possible for root to disable selinux enforcement? A user could maybe even use a livecd if root couldn't be gained directly. I'm looking at joining workstations to an idm realm, but some users will need sudo permissions on their machines. Is there any documentation on best practices here? Has there been any further discussion on the best way to approach this problem? Thanks, *Steve Dainard * IT Infrastructure Manager Miovision http://miovision.com/ | *Rethink Traffic* *Blog http://miovision.com/blog | **LinkedIn https://www.linkedin.com/company/miovision-technologies | Twitter https://twitter.com/miovision | Facebook https://www.facebook.com/miovision* -- Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. On Fri, Nov 29, 2013 at 9:41 AM, Martin Kosek mko...@redhat.com wrote: On 11/29/2013 03:17 PM, Jakub Hrozek wrote: On Fri, Nov 29, 2013 at 03:08:44PM +0100, Fred van Zwieten wrote: Jakub, Yes, I could do this. But then the local root account cannot su to local users (without password). But that is actually a normal use-case. I just think local root should not be allowed to transition to a domain user, by default. Fred Ah, in that case I'm not sure if there's an easy solution, at least I don't know any off hand. I think Alexander is right that SELinux would be a good choice. Right. Root could uncomment the pam_rootok.so line anyway if he wanted to access other user's account again. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] local root can su to any IPA user
Hi, When being root on an ipa-client, I can su to any IPA user. This is somewhat unexptected behaviour in comparison to Windows. If I am local administrator in a windows AD member server, I cannot become a domain user. I need to be domain administrator for that. Is it possible to have this feature disabled somehow? Fred ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] local root can su to any IPA user
On Fri, 29 Nov 2013, Fred van Zwieten wrote: Hi, When being root on an ipa-client, I can su to any IPA user. This is somewhat unexptected behaviour in comparison to Windows. If I am local administrator in a windows AD member server, I cannot become a domain user. I need to be domain administrator for that. Is it possible to have this feature disabled somehow? root user on Linux systems by default has CAP_SETUID capability which allows to change process uid to a different user. If the capability is there, the only way to reduce transition from a specific user to another one is by confining it via appropriate security module, for example, through properly defined SELinux policy that prevents a root to transition to the context of an IPA user. Someone needs to write this policy and deploy at IPA clients first. -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] local root can su to any IPA user
Jakub, Yes, I could do this. But then the local root account cannot su to local users (without password). But that is actually a normal use-case. I just think local root should not be allowed to transition to a domain user, by default. Fred On Fri, Nov 29, 2013 at 2:48 PM, Jakub Hrozek jhro...@redhat.com wrote: On Fri, Nov 29, 2013 at 03:11:01PM +0200, Alexander Bokovoy wrote: On Fri, 29 Nov 2013, Fred van Zwieten wrote: Hi, When being root on an ipa-client, I can su to any IPA user. This is somewhat unexptected behaviour in comparison to Windows. If I am local administrator in a windows AD member server, I cannot become a domain user. I need to be domain administrator for that. Is it possible to have this feature disabled somehow? root user on Linux systems by default has CAP_SETUID capability which allows to change process uid to a different user. If the capability is there, the only way to reduce transition from a specific user to another one is by confining it via appropriate security module, for example, through properly defined SELinux policy that prevents a root to transition to the context of an IPA user. Someone needs to write this policy and deploy at IPA clients first. I think Fred is actually referring to the pam_rootok.so module that always returns PAM_SUCCESS if the caller has UID 0. Fred, if you comment out the line with pam_rootok.so in the file /etc/pam.d/su can you still log in as any user from root? ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] local root can su to any IPA user
On Fri, Nov 29, 2013 at 03:08:44PM +0100, Fred van Zwieten wrote: Jakub, Yes, I could do this. But then the local root account cannot su to local users (without password). But that is actually a normal use-case. I just think local root should not be allowed to transition to a domain user, by default. Fred Ah, in that case I'm not sure if there's an easy solution, at least I don't know any off hand. I think Alexander is right that SELinux would be a good choice. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] local root can su to any IPA user
On 11/29/2013 03:17 PM, Jakub Hrozek wrote: On Fri, Nov 29, 2013 at 03:08:44PM +0100, Fred van Zwieten wrote: Jakub, Yes, I could do this. But then the local root account cannot su to local users (without password). But that is actually a normal use-case. I just think local root should not be allowed to transition to a domain user, by default. Fred Ah, in that case I'm not sure if there's an easy solution, at least I don't know any off hand. I think Alexander is right that SELinux would be a good choice. Right. Root could uncomment the pam_rootok.so line anyway if he wanted to access other user's account again. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
