Simo, Gunther, others,
There has been a recent discussion on sssd-devel regarding whether sssd's AD-GPO effort should support additional logon rights (in addition to the InteractiveLogonRight that we are currently planning on supporting). As you may know, there are five windows logon types: * InteractiveLogonRight Allows a user to log on locally at the computers keyboard. * RemoteInteractiveLogonRight Allow logon through RDP/Terminal Services * NetworkLogonRight Determines which users are allowed to connect over the network to the computer. * BatchLogonRight Allows a user to log on by using a batch-queue facility. * ServiceLogonRight Allows a security principal to log on as a service. Services can be configured to run under the
There is some confusion about the NetworkLogonRight. My initial assumption was that the NetworkLogonRight referred to logging in to a windows computer over the network (e.g. by using ssh). With this assumption in mind, I thought that it would be very useful to additionally support the SeNetworkLogonRight in order to distinguish between these common use cases (network logon vs local logon); this would require us to map the various pam service names into either the "network" bucket or the "local" bucket (probably by including an ad-gpo-specific option with reasonable defaults).
However, since windows users typically use RDP (and not ssh) to perform remote network logon, and since there is a separate RemoteInteractiveLogonRight to cover that case, it is unclear what the NetworkLogonRight actually refers to. Some web sites indicate that NetworkLogon refers to connecting to a shared folder on a windows computer from elsewhere on the network. If NetworkLogon refers to accessing SMB shares, then I think the case for supporting NetworkLogonRight is less compelling. In this case, perhaps we should stay with only supporting the InteractiveLogonRight policy.
Comments?
Thanks, Yassir.
On Thu, 2014-06-19 at 09:15 -0400, Yassir Elley wrote:
Simo, Gunther, others,
There has been a recent discussion on sssd-devel regarding whether sssd's AD-GPO effort should support additional logon rights (in addition to the InteractiveLogonRight that we are currently planning on supporting). As you may know, there are five windows logon types:
- InteractiveLogonRight Allows a user to log on locally at the computers keyboard.
- RemoteInteractiveLogonRight Allow logon through RDP/Terminal Services
- NetworkLogonRight Determines which users are allowed to connect over the network to the computer.
- BatchLogonRight Allows a user to log on by using a batch-queue facility.
- ServiceLogonRight Allows a security principal to log on as a service. Services can be configured to run under the
There is some confusion about the NetworkLogonRight. My initial assumption was that the NetworkLogonRight referred to logging in to a windows computer over the network (e.g. by using ssh). With this assumption in mind,
wrong assumption :-) NetworkLogonRight refers to things like SMB/CIFS, that is, the ability to access "stuff" (with authentication) via the network.
I thought that it would be very useful to additionally support the SeNetworkLogonRight in order to distinguish between these common use cases (network logon vs local logon); this would require us to map the various pam service names into either the "network" bucket or the "local" bucket (probably by including an ad-gpo-specific option with reasonable defaults).
The problem is that you need to be able to edit this list. And you may want to do it both centrally (if someone has homogeneous services) or locally (or at least be able to specify different mappings for different classes of machines). It seem this quickly lead to wanting a GPO to ship this info ...
However, since windows users typically use RDP (and not ssh) to perform remote network logon, and since there is a separate RemoteInteractiveLogonRight to cover that case, it is unclear what the NetworkLogonRight actually refers to. Some web sites indicate that NetworkLogon refers to connecting to a shared folder on a windows computer from elsewhere on the network. If NetworkLogon refers to accessing SMB shares,
It does.
then I think the case for supporting NetworkLogonRight is less compelling.
Although it may make sense to restrict who can access to shares, it is indeed less compelling, and also difficult to implement as a lot of software does not have a centralized/able way to do it.
For example, I would consider scp/sftp a prime candidate for being blocked by NetworkLogonRight (while ssh would use RemoteInteractiveLogonRight), but I do not know how you would go and enforce the difference.
In this case, perhaps we should stay with only supporting the InteractiveLogonRight policy.
Comments?
Supporting RemoteInteractiveLogonRight for SSH is a good idea IMO.
Simo.
----- Original Message -----
On Thu, 2014-06-19 at 09:15 -0400, Yassir Elley wrote:
Simo, Gunther, others,
There has been a recent discussion on sssd-devel regarding whether sssd's AD-GPO effort should support additional logon rights (in addition to the InteractiveLogonRight that we are currently planning on supporting). As you may know, there are five windows logon types:
- InteractiveLogonRight Allows a user to log on locally at
the computers keyboard.
- RemoteInteractiveLogonRight Allow logon through RDP/Terminal
Services
- NetworkLogonRight Determines which users are allowed to
connect over the network to the computer.
- BatchLogonRight Allows a user to log on by using a
batch-queue facility.
- ServiceLogonRight Allows a security principal to log on
as a service. Services can be configured to run under the
There is some confusion about the NetworkLogonRight. My initial assumption was that the NetworkLogonRight referred to logging in to a windows computer over the network (e.g. by using ssh). With this assumption in mind,
wrong assumption :-) NetworkLogonRight refers to things like SMB/CIFS, that is, the ability to access "stuff" (with authentication) via the network.
I thought that it would be very useful to additionally support the SeNetworkLogonRight in order to distinguish between these common use cases (network logon vs local logon); this would require us to map the various pam service names into either the "network" bucket or the "local" bucket (probably by including an ad-gpo-specific option with reasonable defaults).
The problem is that you need to be able to edit this list. And you may want to do it both centrally (if someone has homogeneous services) or locally (or at least be able to specify different mappings for different classes of machines). It seem this quickly lead to wanting a GPO to ship this info ...
However, since windows users typically use RDP (and not ssh) to perform remote network logon, and since there is a separate RemoteInteractiveLogonRight to cover that case, it is unclear what the NetworkLogonRight actually refers to. Some web sites indicate that NetworkLogon refers to connecting to a shared folder on a windows computer from elsewhere on the network. If NetworkLogon refers to accessing SMB shares,
It does.
then I think the case for supporting NetworkLogonRight is less compelling.
Although it may make sense to restrict who can access to shares, it is indeed less compelling, and also difficult to implement as a lot of software does not have a centralized/able way to do it.
For example, I would consider scp/sftp a prime candidate for being blocked by NetworkLogonRight (while ssh would use RemoteInteractiveLogonRight), but I do not know how you would go and enforce the difference.
In this case, perhaps we should stay with only supporting the InteractiveLogonRight policy.
Comments?
Supporting RemoteInteractiveLogonRight for SSH is a good idea IMO.
Simo.
I think you are suggesting using RemoteInteractiveLogonRight for the "ssh" pam service name, and using InteractiveLogonRight for all other pam service names. Is that right?
Thanks, Yassir.
On Thu, 2014-06-19 at 21:29 -0400, Yassir Elley wrote:
----- Original Message -----
On Thu, 2014-06-19 at 09:15 -0400, Yassir Elley wrote:
Simo, Gunther, others,
There has been a recent discussion on sssd-devel regarding whether sssd's AD-GPO effort should support additional logon rights (in addition to the InteractiveLogonRight that we are currently planning on supporting). As you may know, there are five windows logon types:
- InteractiveLogonRight Allows a user to log on locally at
the computers keyboard.
- RemoteInteractiveLogonRight Allow logon through RDP/Terminal
Services
- NetworkLogonRight Determines which users are allowed to
connect over the network to the computer.
- BatchLogonRight Allows a user to log on by using a
batch-queue facility.
- ServiceLogonRight Allows a security principal to log on
as a service. Services can be configured to run under the
There is some confusion about the NetworkLogonRight. My initial assumption was that the NetworkLogonRight referred to logging in to a windows computer over the network (e.g. by using ssh). With this assumption in mind,
wrong assumption :-) NetworkLogonRight refers to things like SMB/CIFS, that is, the ability to access "stuff" (with authentication) via the network.
I thought that it would be very useful to additionally support the SeNetworkLogonRight in order to distinguish between these common use cases (network logon vs local logon); this would require us to map the various pam service names into either the "network" bucket or the "local" bucket (probably by including an ad-gpo-specific option with reasonable defaults).
The problem is that you need to be able to edit this list. And you may want to do it both centrally (if someone has homogeneous services) or locally (or at least be able to specify different mappings for different classes of machines). It seem this quickly lead to wanting a GPO to ship this info ...
However, since windows users typically use RDP (and not ssh) to perform remote network logon, and since there is a separate RemoteInteractiveLogonRight to cover that case, it is unclear what the NetworkLogonRight actually refers to. Some web sites indicate that NetworkLogon refers to connecting to a shared folder on a windows computer from elsewhere on the network. If NetworkLogon refers to accessing SMB shares,
It does.
then I think the case for supporting NetworkLogonRight is less compelling.
Although it may make sense to restrict who can access to shares, it is indeed less compelling, and also difficult to implement as a lot of software does not have a centralized/able way to do it.
For example, I would consider scp/sftp a prime candidate for being blocked by NetworkLogonRight (while ssh would use RemoteInteractiveLogonRight), but I do not know how you would go and enforce the difference.
In this case, perhaps we should stay with only supporting the InteractiveLogonRight policy.
Comments?
Supporting RemoteInteractiveLogonRight for SSH is a good idea IMO.
Simo.
I think you are suggesting using RemoteInteractiveLogonRight for the "ssh" pam service name, and using InteractiveLogonRight for all other pam service names. Is that right?
Uhmm not exactly. I am for using RemoteInteractiveLogonRight for the ssh pam service, yes.
But InteractiveLogonRight for most of the others is probably wrong. Services like ftp, samba, imap, smtp, pop, etc.. clearly should be mapped to NetworkLogonRight.
Really the only services that should have InteractiveLogonRight are gdm (and all *dm) and login, perhaps also su/su-l/sudo/sudo-l ?
Simo.
----- Original Message -----
On Thu, 2014-06-19 at 21:29 -0400, Yassir Elley wrote:
----- Original Message -----
On Thu, 2014-06-19 at 09:15 -0400, Yassir Elley wrote:
Simo, Gunther, others,
There has been a recent discussion on sssd-devel regarding whether sssd's AD-GPO effort should support additional logon rights (in addition to the InteractiveLogonRight that we are currently planning on supporting). As you may know, there are five windows logon types:
- InteractiveLogonRight Allows a user to log on locally
at the computers keyboard.
- RemoteInteractiveLogonRight Allow logon through RDP/Terminal
Services
- NetworkLogonRight Determines which users are
allowed to connect over the network to the computer.
- BatchLogonRight Allows a user to log on by using
a batch-queue facility.
- ServiceLogonRight Allows a security principal to
log on as a service. Services can be configured to run under the
There is some confusion about the NetworkLogonRight. My initial assumption was that the NetworkLogonRight referred to logging in to a windows computer over the network (e.g. by using ssh). With this assumption in mind,
wrong assumption :-) NetworkLogonRight refers to things like SMB/CIFS, that is, the ability to access "stuff" (with authentication) via the network.
I thought that it would be very useful to additionally support the SeNetworkLogonRight in order to distinguish between these common use cases (network logon vs local logon); this would require us to map the various pam service names into either the "network" bucket or the "local" bucket (probably by including an ad-gpo-specific option with reasonable defaults).
The problem is that you need to be able to edit this list. And you may want to do it both centrally (if someone has homogeneous services) or locally (or at least be able to specify different mappings for different classes of machines). It seem this quickly lead to wanting a GPO to ship this info ...
However, since windows users typically use RDP (and not ssh) to perform remote network logon, and since there is a separate RemoteInteractiveLogonRight to cover that case, it is unclear what the NetworkLogonRight actually refers to. Some web sites indicate that NetworkLogon refers to connecting to a shared folder on a windows computer from elsewhere on the network. If NetworkLogon refers to accessing SMB shares,
It does.
then I think the case for supporting NetworkLogonRight is less compelling.
Although it may make sense to restrict who can access to shares, it is indeed less compelling, and also difficult to implement as a lot of software does not have a centralized/able way to do it.
For example, I would consider scp/sftp a prime candidate for being blocked by NetworkLogonRight (while ssh would use RemoteInteractiveLogonRight), but I do not know how you would go and enforce the difference.
In this case, perhaps we should stay with only supporting the InteractiveLogonRight policy.
Comments?
Supporting RemoteInteractiveLogonRight for SSH is a good idea IMO.
Simo.
I think you are suggesting using RemoteInteractiveLogonRight for the "ssh" pam service name, and using InteractiveLogonRight for all other pam service names. Is that right?
Uhmm not exactly. I am for using RemoteInteractiveLogonRight for the ssh pam service, yes.
But InteractiveLogonRight for most of the others is probably wrong. Services like ftp, samba, imap, smtp, pop, etc.. clearly should be mapped to NetworkLogonRight.
Really the only services that should have InteractiveLogonRight are gdm (and all *dm) and login, perhaps also su/su-l/sudo/sudo-l ?
Simo.
You mentioned that the NetworkLogonRight case would be difficult to implement (e.g. ftp, samba, imap, smtp, pop, etc). Is that because those applications don't call pam_acct_mgmt?
If so, perhaps we should focus only on the InteractiveLogonRight (for the pam services you mention above: "login", etc) and RemoteInteractiveLogonRight (for the "ssh" pam service).
Regards, Yassir.
----- Original Message -----
----- Original Message -----
On Thu, 2014-06-19 at 21:29 -0400, Yassir Elley wrote:
----- Original Message -----
On Thu, 2014-06-19 at 09:15 -0400, Yassir Elley wrote:
Simo, Gunther, others,
There has been a recent discussion on sssd-devel regarding whether sssd's AD-GPO effort should support additional logon rights (in addition to the InteractiveLogonRight that we are currently planning on supporting). As you may know, there are five windows logon types:
- InteractiveLogonRight Allows a user to log on locally
at the computers keyboard.
- RemoteInteractiveLogonRight Allow logon through
RDP/Terminal Services
- NetworkLogonRight Determines which users are
allowed to connect over the network to the computer.
- BatchLogonRight Allows a user to log on by
using a batch-queue facility.
- ServiceLogonRight Allows a security principal to
log on as a service. Services can be configured to run under the
There is some confusion about the NetworkLogonRight. My initial assumption was that the NetworkLogonRight referred to logging in to a windows computer over the network (e.g. by using ssh). With this assumption in mind,
wrong assumption :-) NetworkLogonRight refers to things like SMB/CIFS, that is, the ability to access "stuff" (with authentication) via the network.
I thought that it would be very useful to additionally support the SeNetworkLogonRight in order to distinguish between these common use cases (network logon vs local logon); this would require us to map the various pam service names into either the "network" bucket or the "local" bucket (probably by including an ad-gpo-specific option with reasonable defaults).
The problem is that you need to be able to edit this list. And you may want to do it both centrally (if someone has homogeneous services) or locally (or at least be able to specify different mappings for different classes of machines). It seem this quickly lead to wanting a GPO to ship this info ...
However, since windows users typically use RDP (and not ssh) to perform remote network logon, and since there is a separate RemoteInteractiveLogonRight to cover that case, it is unclear what the NetworkLogonRight actually refers to. Some web sites indicate that NetworkLogon refers to connecting to a shared folder on a windows computer from elsewhere on the network. If NetworkLogon refers to accessing SMB shares,
It does.
then I think the case for supporting NetworkLogonRight is less compelling.
Although it may make sense to restrict who can access to shares, it is indeed less compelling, and also difficult to implement as a lot of software does not have a centralized/able way to do it.
For example, I would consider scp/sftp a prime candidate for being blocked by NetworkLogonRight (while ssh would use RemoteInteractiveLogonRight), but I do not know how you would go and enforce the difference.
In this case, perhaps we should stay with only supporting the InteractiveLogonRight policy.
Comments?
Supporting RemoteInteractiveLogonRight for SSH is a good idea IMO.
Simo.
I think you are suggesting using RemoteInteractiveLogonRight for the "ssh" pam service name, and using InteractiveLogonRight for all other pam service names. Is that right?
Uhmm not exactly. I am for using RemoteInteractiveLogonRight for the ssh pam service, yes.
But InteractiveLogonRight for most of the others is probably wrong. Services like ftp, samba, imap, smtp, pop, etc.. clearly should be mapped to NetworkLogonRight.
Really the only services that should have InteractiveLogonRight are gdm (and all *dm) and login, perhaps also su/su-l/sudo/sudo-l ?
Simo.
You mentioned that the NetworkLogonRight case would be difficult to implement (e.g. ftp, samba, imap, smtp, pop, etc). Is that because those applications don't call pam_acct_mgmt?
If so, perhaps we should focus only on the InteractiveLogonRight (for the pam services you mention above: "login", etc) and RemoteInteractiveLogonRight (for the "ssh" pam service).
Regards, Yassir.
Hi Simo,
I'd like to wrap up this discussion. I propose that we support only the InteractiveLogonRight (for the pam services you mentioned: "login", "*dm, "su*"), and on the RemoteInteractiveLogonRight (for the "ssh" pam service). We should not support the NetworkLogonRight since it is difficult to implement. Do you agree with this proposal?
Thanks, Yassir.
On Thu, Jun 26, 2014 at 04:54:41AM -0400, Yassir Elley wrote:
----- Original Message -----
----- Original Message -----
On Thu, 2014-06-19 at 21:29 -0400, Yassir Elley wrote:
----- Original Message -----
On Thu, 2014-06-19 at 09:15 -0400, Yassir Elley wrote:
Simo, Gunther, others,
There has been a recent discussion on sssd-devel regarding whether sssd's AD-GPO effort should support additional logon rights (in addition to the InteractiveLogonRight that we are currently planning on supporting). As you may know, there are five windows logon types:
- InteractiveLogonRight Allows a user to log on locally
at the computers keyboard.
- RemoteInteractiveLogonRight Allow logon through
RDP/Terminal Services
- NetworkLogonRight Determines which users are
allowed to connect over the network to the computer.
- BatchLogonRight Allows a user to log on by
using a batch-queue facility.
- ServiceLogonRight Allows a security principal to
log on as a service. Services can be configured to run under the
There is some confusion about the NetworkLogonRight. My initial assumption was that the NetworkLogonRight referred to logging in to a windows computer over the network (e.g. by using ssh). With this assumption in mind,
wrong assumption :-) NetworkLogonRight refers to things like SMB/CIFS, that is, the ability to access "stuff" (with authentication) via the network.
I thought that it would be very useful to additionally support the SeNetworkLogonRight in order to distinguish between these common use cases (network logon vs local logon); this would require us to map the various pam service names into either the "network" bucket or the "local" bucket (probably by including an ad-gpo-specific option with reasonable defaults).
The problem is that you need to be able to edit this list. And you may want to do it both centrally (if someone has homogeneous services) or locally (or at least be able to specify different mappings for different classes of machines). It seem this quickly lead to wanting a GPO to ship this info ...
However, since windows users typically use RDP (and not ssh) to perform remote network logon, and since there is a separate RemoteInteractiveLogonRight to cover that case, it is unclear what the NetworkLogonRight actually refers to. Some web sites indicate that NetworkLogon refers to connecting to a shared folder on a windows computer from elsewhere on the network. If NetworkLogon refers to accessing SMB shares,
It does.
then I think the case for supporting NetworkLogonRight is less compelling.
Although it may make sense to restrict who can access to shares, it is indeed less compelling, and also difficult to implement as a lot of software does not have a centralized/able way to do it.
For example, I would consider scp/sftp a prime candidate for being blocked by NetworkLogonRight (while ssh would use RemoteInteractiveLogonRight), but I do not know how you would go and enforce the difference.
In this case, perhaps we should stay with only supporting the InteractiveLogonRight policy.
Comments?
Supporting RemoteInteractiveLogonRight for SSH is a good idea IMO.
Simo.
I think you are suggesting using RemoteInteractiveLogonRight for the "ssh" pam service name, and using InteractiveLogonRight for all other pam service names. Is that right?
Uhmm not exactly. I am for using RemoteInteractiveLogonRight for the ssh pam service, yes.
But InteractiveLogonRight for most of the others is probably wrong. Services like ftp, samba, imap, smtp, pop, etc.. clearly should be mapped to NetworkLogonRight.
Really the only services that should have InteractiveLogonRight are gdm (and all *dm) and login, perhaps also su/su-l/sudo/sudo-l ?
Simo.
You mentioned that the NetworkLogonRight case would be difficult to implement (e.g. ftp, samba, imap, smtp, pop, etc). Is that because those applications don't call pam_acct_mgmt?
If so, perhaps we should focus only on the InteractiveLogonRight (for the pam services you mention above: "login", etc) and RemoteInteractiveLogonRight (for the "ssh" pam service).
Regards, Yassir.
Hi Simo,
I'd like to wrap up this discussion. I propose that we support only the InteractiveLogonRight (for the pam services you mentioned: "login", "*dm, "su*"), and on the RemoteInteractiveLogonRight (for the "ssh" pam service). We should not support the NetworkLogonRight since it is difficult to implement. Do you agree with this proposal?
What about all the other PAM services?
bye, Sumit
Thanks, Yassir. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On Thu, 2014-06-26 at 04:54 -0400, Yassir Elley wrote:
Hi Simo,
I'd like to wrap up this discussion. I propose that we support only the InteractiveLogonRight (for the pam services you mentioned: "login", "*dm, "su*"), and on the RemoteInteractiveLogonRight (for the "ssh" pam service). We should not support the NetworkLogonRight since it is difficult to implement. Do you agree with this proposal?
Well I guess the answer depends on what do you plan to do for pam services that are not listed ? Do you always deny access ? Always permit ?
I think a more reasonable workaround is to define a default type, and a list of mappings.
If a PAM service is explicitly mapped you use that Right to decide, otherwise the decision falls back to the "default" Right. Actually the default right could well be actually NetworkLogonRight or InteractiveLogonRight or something else. As long as you can change the mappings locally through some configuration that would allow the admin to add mappings according to their needs. Of course strong guidance on which mappings should be used for specific type of services should be provided.
Simo.
----- Original Message -----
On Thu, 2014-06-26 at 04:54 -0400, Yassir Elley wrote:
Hi Simo,
I'd like to wrap up this discussion. I propose that we support only the InteractiveLogonRight (for the pam services you mentioned: "login", "*dm, "su*"), and on the RemoteInteractiveLogonRight (for the "ssh" pam service). We should not support the NetworkLogonRight since it is difficult to implement. Do you agree with this proposal?
Well I guess the answer depends on what do you plan to do for pam services that are not listed ? Do you always deny access ? Always permit ?
Since we would only support the InteractiveLogonRight and RemoteInteractiveLogonRight, we would always permit access for other pam services (because they would not be governed by gpo-based access control, and this would be clearly documented).
I think a more reasonable workaround is to define a default type, and a list of mappings.
If a PAM service is explicitly mapped you use that Right to decide, otherwise the decision falls back to the "default" Right. Actually the default right could well be actually NetworkLogonRight or InteractiveLogonRight or something else. As long as you can change the mappings locally through some configuration that would allow the admin to add mappings according to their needs. Of course strong guidance on which mappings should be used for specific type of services should be provided.
Simo.
I would prefer an approach which is more predictable for the AD admin. If we limit ourselves to InteractiveLogonRight and RemoteInteractiveLogonRight, the semantics are very clear (console login and remote login), allowing the AD Admin to be confident that any existing or future policy files containing those rights would be applied correctly and consistently, regardless of whether the machine is running Linux or Windows.
Also, I suspect AD admins would not like per-machine service mappings to be enforced, since that would defeat the purpose of enforcing a centralized policy in a consistent manner. When an AD admin made a change to a LogonRight policy setting, he would have to keep in mind that Linux machines may use the policy settings in ways that were not intended by the AD admin. For example, it would be problematic if a local admin decided to map "login" to NetworkLogonRight, or if some local admins mapped "ftp" to some LogonRight (but other local admins stayed with the default). This would result in inconsistent behavior between different Linux machines, and between Linux machines and Windows machines. Indeed, in the Windows world, the "local" per-machine GPO is given least priority in case of conflict (i.e. ou overrides domain, which overrides site, which overrides local). A solution to this problem of consistency would be to have a centralized GPO that maps pam services to LogonRights, but I don't think we need to implement that in the first release.
I think limiting ourselves to InteractiveLogonRight and RemoteInteractiveLogonRight would be less confusing and more predictable for AD admins (resulting in a greater likelihood of them deploying gpo-based access control). They would know that these two LogonRights would be enforced with the same semantics on Windows and Linux machines. They would also know that other LogonRights would not be enforced on Linux machines. Clean and crisp.
What do you think?
Regards, Yassir.
On Sat, 2014-06-28 at 01:20 -0400, Yassir Elley wrote:
----- Original Message -----
On Thu, 2014-06-26 at 04:54 -0400, Yassir Elley wrote:
Hi Simo,
I'd like to wrap up this discussion. I propose that we support only the InteractiveLogonRight (for the pam services you mentioned: "login", "*dm, "su*"), and on the RemoteInteractiveLogonRight (for the "ssh" pam service). We should not support the NetworkLogonRight since it is difficult to implement. Do you agree with this proposal?
Well I guess the answer depends on what do you plan to do for pam services that are not listed ? Do you always deny access ? Always permit ?
Since we would only support the InteractiveLogonRight and RemoteInteractiveLogonRight, we would always permit access for other pam services (because they would not be governed by gpo-based access control, and this would be clearly documented).
I think a more reasonable workaround is to define a default type, and a list of mappings.
If a PAM service is explicitly mapped you use that Right to decide, otherwise the decision falls back to the "default" Right. Actually the default right could well be actually NetworkLogonRight or InteractiveLogonRight or something else. As long as you can change the mappings locally through some configuration that would allow the admin to add mappings according to their needs. Of course strong guidance on which mappings should be used for specific type of services should be provided.
Simo.
I would prefer an approach which is more predictable for the AD admin. If we limit ourselves to InteractiveLogonRight and RemoteInteractiveLogonRight, the semantics are very clear (console login and remote login), allowing the AD Admin to be confident that any existing or future policy files containing those rights would be applied correctly and consistently, regardless of whether the machine is running Linux or Windows.
Also, I suspect AD admins would not like per-machine service mappings to be enforced, since that would defeat the purpose of enforcing a centralized policy in a consistent manner. When an AD admin made a change to a LogonRight policy setting, he would have to keep in mind that Linux machines may use the policy settings in ways that were not intended by the AD admin. For example, it would be problematic if a local admin decided to map "login" to NetworkLogonRight, or if some local admins mapped "ftp" to some LogonRight (but other local admins stayed with the default). This would result in inconsistent behavior between different Linux machines, and between Linux machines and Windows machines. Indeed, in the Windows world, the "local" per-machine GPO is given least priority in case of conflict (i.e. ou overrides domain, which overrides site, which overrides local). A solution to this problem of consistency would be to have a centralized GPO that maps pam services to LogonRights, but I don't think we need to implement that in the first release.
I think limiting ourselves to InteractiveLogonRight and RemoteInteractiveLogonRight would be less confusing and more predictable for AD admins (resulting in a greater likelihood of them deploying gpo-based access control). They would know that these two LogonRights would be enforced with the same semantics on Windows and Linux machines. They would also know that other LogonRights would not be enforced on Linux machines. Clean and crisp.
What do you think?
You make a good argument, but I am not entirely convinced you can avoid a local mapping unless you provide a GPO mapping, because the admin must be able to adjust mappings for new services installed on the box that were not included in the upstream provided lists.
So if you already need to provide a way to augment mappings, you may as well handle all rights with reasonable defaults, and let the admin decide whether they need to change stuff around.
Simo.
----- Original Message -----
On Sat, 2014-06-28 at 01:20 -0400, Yassir Elley wrote:
----- Original Message -----
On Thu, 2014-06-26 at 04:54 -0400, Yassir Elley wrote:
Hi Simo,
I'd like to wrap up this discussion. I propose that we support only the InteractiveLogonRight (for the pam services you mentioned: "login", "*dm, "su*"), and on the RemoteInteractiveLogonRight (for the "ssh" pam service). We should not support the NetworkLogonRight since it is difficult to implement. Do you agree with this proposal?
Well I guess the answer depends on what do you plan to do for pam services that are not listed ? Do you always deny access ? Always permit ?
Since we would only support the InteractiveLogonRight and RemoteInteractiveLogonRight, we would always permit access for other pam services (because they would not be governed by gpo-based access control, and this would be clearly documented).
I think a more reasonable workaround is to define a default type, and a list of mappings.
If a PAM service is explicitly mapped you use that Right to decide, otherwise the decision falls back to the "default" Right. Actually the default right could well be actually NetworkLogonRight or InteractiveLogonRight or something else. As long as you can change the mappings locally through some configuration that would allow the admin to add mappings according to their needs. Of course strong guidance on which mappings should be used for specific type of services should be provided.
Simo.
I would prefer an approach which is more predictable for the AD admin. If we limit ourselves to InteractiveLogonRight and RemoteInteractiveLogonRight, the semantics are very clear (console login and remote login), allowing the AD Admin to be confident that any existing or future policy files containing those rights would be applied correctly and consistently, regardless of whether the machine is running Linux or Windows.
Also, I suspect AD admins would not like per-machine service mappings to be enforced, since that would defeat the purpose of enforcing a centralized policy in a consistent manner. When an AD admin made a change to a LogonRight policy setting, he would have to keep in mind that Linux machines may use the policy settings in ways that were not intended by the AD admin. For example, it would be problematic if a local admin decided to map "login" to NetworkLogonRight, or if some local admins mapped "ftp" to some LogonRight (but other local admins stayed with the default). This would result in inconsistent behavior between different Linux machines, and between Linux machines and Windows machines. Indeed, in the Windows world, the "local" per-machine GPO is given least priority in case of conflict (i.e. ou overrides domain, which overrides site, which overrides local). A solution to this problem of consistency would be to have a centralized GPO that maps pam services to LogonRights, but I don't think we need to implement that in the first release.
I think limiting ourselves to InteractiveLogonRight and RemoteInteractiveLogonRight would be less confusing and more predictable for AD admins (resulting in a greater likelihood of them deploying gpo-based access control). They would know that these two LogonRights would be enforced with the same semantics on Windows and Linux machines. They would also know that other LogonRights would not be enforced on Linux machines. Clean and crisp.
What do you think?
You make a good argument, but I am not entirely convinced you can avoid a local mapping unless you provide a GPO mapping, because the admin must be able to adjust mappings for new services installed on the box that were not included in the upstream provided lists.
So if you already need to provide a way to augment mappings, you may as well handle all rights with reasonable defaults, and let the admin decide whether they need to change stuff around.
Simo.
Allowing local admins to change stuff from underneath the AD admin's directives seems to violate the GPO philosophy of centralized, consistent application of policy. I don't think AD admins will find the gpo-based access control feature compelling, if it does not fit with their mental model of how GPO is supposed to work. As you know, LogonRights are existing Windows policy settings (not Linux-specific settings), so we really do have to honor the intent of the settings and the GPO framework. Having said that, I don't think we necessarily need to have a comprehensive implementation in the first release, especially if we think the GPO mapping is the correct solution (and if we think that we may implement that in a subsequent release). I think the centralized mapping offered by a future GPO mapping would certainly allay the concerns of AD admins, as the power would remain in their hands and it would be applied consistently. Implementing local mapping now, and then adding a centralized mapping later would delay deployment and would add too much complexity IMO.
As for how to deal with new services (in the initial implementation), two ideas come to mind: 1) My preference would be that only services included in the upstream provided lists will be affected by gpo-based access control. Not very extensible, but that's OK if we intend on adding a GPO mapping in a future release. 2) Alternatively, we could go with a completely different proposal that would affect all pam services. Specifically, since remote login seems to be an uncommon pam service (we could only come up with "ssh"), we could declare that "ssh" maps to RemoteInteractiveLogonRight, and that *all* other services (including new services, custom services, etc), map to InteractiveLogonRight. While certainly not ideal (and not my preference), I think AD admins would find this easier to grok than local mappings, as it would be predictable and would allow policy authority to remain centralized, without central directives being manipulated by local admins.
Regards, Yassir.
On Sat, 2014-06-28 at 18:01 -0400, Yassir Elley wrote:
----- Original Message -----
On Sat, 2014-06-28 at 01:20 -0400, Yassir Elley wrote:
----- Original Message -----
On Thu, 2014-06-26 at 04:54 -0400, Yassir Elley wrote:
Hi Simo,
I'd like to wrap up this discussion. I propose that we support only the InteractiveLogonRight (for the pam services you mentioned: "login", "*dm, "su*"), and on the RemoteInteractiveLogonRight (for the "ssh" pam service). We should not support the NetworkLogonRight since it is difficult to implement. Do you agree with this proposal?
Well I guess the answer depends on what do you plan to do for pam services that are not listed ? Do you always deny access ? Always permit ?
Since we would only support the InteractiveLogonRight and RemoteInteractiveLogonRight, we would always permit access for other pam services (because they would not be governed by gpo-based access control, and this would be clearly documented).
I think a more reasonable workaround is to define a default type, and a list of mappings.
If a PAM service is explicitly mapped you use that Right to decide, otherwise the decision falls back to the "default" Right. Actually the default right could well be actually NetworkLogonRight or InteractiveLogonRight or something else. As long as you can change the mappings locally through some configuration that would allow the admin to add mappings according to their needs. Of course strong guidance on which mappings should be used for specific type of services should be provided.
Simo.
I would prefer an approach which is more predictable for the AD admin. If we limit ourselves to InteractiveLogonRight and RemoteInteractiveLogonRight, the semantics are very clear (console login and remote login), allowing the AD Admin to be confident that any existing or future policy files containing those rights would be applied correctly and consistently, regardless of whether the machine is running Linux or Windows.
Also, I suspect AD admins would not like per-machine service mappings to be enforced, since that would defeat the purpose of enforcing a centralized policy in a consistent manner. When an AD admin made a change to a LogonRight policy setting, he would have to keep in mind that Linux machines may use the policy settings in ways that were not intended by the AD admin. For example, it would be problematic if a local admin decided to map "login" to NetworkLogonRight, or if some local admins mapped "ftp" to some LogonRight (but other local admins stayed with the default). This would result in inconsistent behavior between different Linux machines, and between Linux machines and Windows machines. Indeed, in the Windows world, the "local" per-machine GPO is given least priority in case of conflict (i.e. ou overrides domain, which overrides site, which overrides local). A solution to this problem of consistency would be to have a centralized GPO that maps pam services to LogonRights, but I don't think we need to implement that in the first release.
I think limiting ourselves to InteractiveLogonRight and RemoteInteractiveLogonRight would be less confusing and more predictable for AD admins (resulting in a greater likelihood of them deploying gpo-based access control). They would know that these two LogonRights would be enforced with the same semantics on Windows and Linux machines. They would also know that other LogonRights would not be enforced on Linux machines. Clean and crisp.
What do you think?
You make a good argument, but I am not entirely convinced you can avoid a local mapping unless you provide a GPO mapping, because the admin must be able to adjust mappings for new services installed on the box that were not included in the upstream provided lists.
So if you already need to provide a way to augment mappings, you may as well handle all rights with reasonable defaults, and let the admin decide whether they need to change stuff around.
Simo.
Allowing local admins to change stuff from underneath the AD admin's directives seems to violate the GPO philosophy of centralized, consistent application of policy. I don't think AD admins will find the gpo-based access control feature compelling, if it does not fit with their mental model of how GPO is supposed to work.
Sorry but I do not buy this argument. The whole GPO policy can be turned on or off in sssd, so if admins do not control the boxes' sssd.conf file they already know their policies are, at best, advisory.
As you know, LogonRights are existing Windows policy settings (not Linux-specific settings), so we really do have to honor the intent of the settings and the GPO framework.
Indeed, and in order to do that you need to be able to appropriately map arbitrary services.
Having said that, I don't think we necessarily need to have a comprehensive implementation in the first release, especially if we think the GPO mapping is the correct solution (and if we think that we may implement that in a subsequent release).
We do not need the support as a GPO deliverable policy, but you need a local mapping for the feature to be usable/testable IMO.
I think the centralized mapping offered by a future GPO mapping would certainly allay the concerns of AD admins, as the power would remain in their hands and it would be applied consistently. Implementing local mapping now, and then adding a centralized mapping later would delay deployment and would add too much complexity IMO.
Why ? This is exactly the same as overlaying global policy on top of local policy, I honestly do not see it as any more complex than needed.
As for how to deal with new services (in the initial implementation), two ideas come to mind:
- My preference would be that only services included in the upstream
provided lists will be affected by gpo-based access control. Not very extensible, but that's OK if we intend on adding a GPO mapping in a future release.
Upstream runs on multiple OSs and Linux distributions, within those there is already, I bet, enough conflict to make a single upstream list unfeasible, as pam service names are somewhat arbitrary and customized in different way especially for very distro-specific services like login and graphical session managers.
- Alternatively, we could go with a completely different proposal
that would affect all pam services. Specifically, since remote login seems to be an uncommon pam service (we could only come up with "ssh"), we could declare that "ssh" maps to RemoteInteractiveLogonRight, and that *all* other services (including new services, custom services, etc), map to InteractiveLogonRight.
That would be wrong. I suspect one of the services you really want to control, as a windows admin, is samba file services, and those must be mapped to NetworkLogonRight. And NEtworkLogonRight seem to be generally the most sensible default once you exclude the services you know are interactive login shells.
While certainly not ideal (and not my preference), I think AD admins would find this easier to grok than local mappings, as it would be predictable and would allow policy authority to remain centralized, without central directives being manipulated by local admins.
If the admin doesn't grok what services run on a Linux box, they are already doomed I would think. You need at least a passing understanding of the policies you are going to set. We can *definitely* provide a good default set, admins should not be required to provide explicit mappings if the default works for them, but an unchangeable list will severely reduce the utility of the feature.
Simo.
----- Original Message -----
On Sat, 2014-06-28 at 18:01 -0400, Yassir Elley wrote:
----- Original Message -----
On Sat, 2014-06-28 at 01:20 -0400, Yassir Elley wrote:
----- Original Message -----
On Thu, 2014-06-26 at 04:54 -0400, Yassir Elley wrote:
Hi Simo,
I'd like to wrap up this discussion. I propose that we support only the InteractiveLogonRight (for the pam services you mentioned: "login", "*dm, "su*"), and on the RemoteInteractiveLogonRight (for the "ssh" pam service). We should not support the NetworkLogonRight since it is difficult to implement. Do you agree with this proposal?
Well I guess the answer depends on what do you plan to do for pam services that are not listed ? Do you always deny access ? Always permit ?
Since we would only support the InteractiveLogonRight and RemoteInteractiveLogonRight, we would always permit access for other pam services (because they would not be governed by gpo-based access control, and this would be clearly documented).
I think a more reasonable workaround is to define a default type, and a list of mappings.
If a PAM service is explicitly mapped you use that Right to decide, otherwise the decision falls back to the "default" Right. Actually the default right could well be actually NetworkLogonRight or InteractiveLogonRight or something else. As long as you can change the mappings locally through some configuration that would allow the admin to add mappings according to their needs. Of course strong guidance on which mappings should be used for specific type of services should be provided.
Simo.
I would prefer an approach which is more predictable for the AD admin. If we limit ourselves to InteractiveLogonRight and RemoteInteractiveLogonRight, the semantics are very clear (console login and remote login), allowing the AD Admin to be confident that any existing or future policy files containing those rights would be applied correctly and consistently, regardless of whether the machine is running Linux or Windows.
Also, I suspect AD admins would not like per-machine service mappings to be enforced, since that would defeat the purpose of enforcing a centralized policy in a consistent manner. When an AD admin made a change to a LogonRight policy setting, he would have to keep in mind that Linux machines may use the policy settings in ways that were not intended by the AD admin. For example, it would be problematic if a local admin decided to map "login" to NetworkLogonRight, or if some local admins mapped "ftp" to some LogonRight (but other local admins stayed with the default). This would result in inconsistent behavior between different Linux machines, and between Linux machines and Windows machines. Indeed, in the Windows world, the "local" per-machine GPO is given least priority in case of conflict (i.e. ou overrides domain, which overrides site, which overrides local). A solution to this problem of consistency would be to have a centralized GPO that maps pam services to LogonRights, but I don't think we need to implement that in the first release.
I think limiting ourselves to InteractiveLogonRight and RemoteInteractiveLogonRight would be less confusing and more predictable for AD admins (resulting in a greater likelihood of them deploying gpo-based access control). They would know that these two LogonRights would be enforced with the same semantics on Windows and Linux machines. They would also know that other LogonRights would not be enforced on Linux machines. Clean and crisp.
What do you think?
You make a good argument, but I am not entirely convinced you can avoid a local mapping unless you provide a GPO mapping, because the admin must be able to adjust mappings for new services installed on the box that were not included in the upstream provided lists.
So if you already need to provide a way to augment mappings, you may as well handle all rights with reasonable defaults, and let the admin decide whether they need to change stuff around.
Simo.
Allowing local admins to change stuff from underneath the AD admin's directives seems to violate the GPO philosophy of centralized, consistent application of policy. I don't think AD admins will find the gpo-based access control feature compelling, if it does not fit with their mental model of how GPO is supposed to work.
Sorry but I do not buy this argument. The whole GPO policy can be turned on or off in sssd, so if admins do not control the boxes' sssd.conf file they already know their policies are, at best, advisory.
As you know, LogonRights are existing Windows policy settings (not Linux-specific settings), so we really do have to honor the intent of the settings and the GPO framework.
Indeed, and in order to do that you need to be able to appropriately map arbitrary services.
Having said that, I don't think we necessarily need to have a comprehensive implementation in the first release, especially if we think the GPO mapping is the correct solution (and if we think that we may implement that in a subsequent release).
We do not need the support as a GPO deliverable policy, but you need a local mapping for the feature to be usable/testable IMO.
I think the centralized mapping offered by a future GPO mapping would certainly allay the concerns of AD admins, as the power would remain in their hands and it would be applied consistently. Implementing local mapping now, and then adding a centralized mapping later would delay deployment and would add too much complexity IMO.
Why ? This is exactly the same as overlaying global policy on top of local policy, I honestly do not see it as any more complex than needed.
As for how to deal with new services (in the initial implementation), two ideas come to mind:
- My preference would be that only services included in the upstream
provided lists will be affected by gpo-based access control. Not very extensible, but that's OK if we intend on adding a GPO mapping in a future release.
Upstream runs on multiple OSs and Linux distributions, within those there is already, I bet, enough conflict to make a single upstream list unfeasible, as pam service names are somewhat arbitrary and customized in different way especially for very distro-specific services like login and graphical session managers.
- Alternatively, we could go with a completely different proposal
that would affect all pam services. Specifically, since remote login seems to be an uncommon pam service (we could only come up with "ssh"), we could declare that "ssh" maps to RemoteInteractiveLogonRight, and that *all* other services (including new services, custom services, etc), map to InteractiveLogonRight.
That would be wrong. I suspect one of the services you really want to control, as a windows admin, is samba file services, and those must be mapped to NetworkLogonRight. And NEtworkLogonRight seem to be generally the most sensible default once you exclude the services you know are interactive login shells.
While certainly not ideal (and not my preference), I think AD admins would find this easier to grok than local mappings, as it would be predictable and would allow policy authority to remain centralized, without central directives being manipulated by local admins.
If the admin doesn't grok what services run on a Linux box, they are already doomed I would think. You need at least a passing understanding of the policies you are going to set. We can *definitely* provide a good default set, admins should not be required to provide explicit mappings if the default works for them, but an unchangeable list will severely reduce the utility of the feature.
OK. I forgot that local admins can disable gpo processing, so although AD admins may want centralized control over all domain computers (whether Windows or Linux), they may not be able to get it with this feature. Whether this will be a show-stopper for them remains to be seen. With that in mind, I agree that it makes sense to allow pam services to be mapped to logon rights.
With regard to the default set of mappings, I propose the following (based on previous emails). login/*dm/su* maps to InteractiveLogonRight ssh maps to RemoteInteractiveLogonRight explicit mappings are honored if the service is still unmapped, map it to NetworkLogonRight
A few questions for you: * Does this list make sense? * Should there be anything special about the default set, or can an admin re-map services from the default set (i.e. map "ssh" to NetworkLogonRight)? * Should an admin be able to map a service to NULL (indicating that they don't want this service to be enforced by GPO policy)
Regards, Yassir.
On Tue, 2014-07-01 at 01:50 -0400, Yassir Elley wrote:
----- Original Message -----
On Sat, 2014-06-28 at 18:01 -0400, Yassir Elley wrote:
----- Original Message -----
On Sat, 2014-06-28 at 01:20 -0400, Yassir Elley wrote:
----- Original Message -----
On Thu, 2014-06-26 at 04:54 -0400, Yassir Elley wrote: > Hi Simo, > > I'd like to wrap up this discussion. I propose that we support only > the InteractiveLogonRight (for the pam services you mentioned: > "login", "*dm, "su*"), and on the RemoteInteractiveLogonRight (for > the > "ssh" pam service). We should not support the NetworkLogonRight > since > it is difficult to implement. Do you agree with this proposal?
Well I guess the answer depends on what do you plan to do for pam services that are not listed ? Do you always deny access ? Always permit ?
Since we would only support the InteractiveLogonRight and RemoteInteractiveLogonRight, we would always permit access for other pam services (because they would not be governed by gpo-based access control, and this would be clearly documented).
I think a more reasonable workaround is to define a default type, and a list of mappings.
If a PAM service is explicitly mapped you use that Right to decide, otherwise the decision falls back to the "default" Right. Actually the default right could well be actually NetworkLogonRight or InteractiveLogonRight or something else. As long as you can change the mappings locally through some configuration that would allow the admin to add mappings according to their needs. Of course strong guidance on which mappings should be used for specific type of services should be provided.
Simo.
I would prefer an approach which is more predictable for the AD admin. If we limit ourselves to InteractiveLogonRight and RemoteInteractiveLogonRight, the semantics are very clear (console login and remote login), allowing the AD Admin to be confident that any existing or future policy files containing those rights would be applied correctly and consistently, regardless of whether the machine is running Linux or Windows.
Also, I suspect AD admins would not like per-machine service mappings to be enforced, since that would defeat the purpose of enforcing a centralized policy in a consistent manner. When an AD admin made a change to a LogonRight policy setting, he would have to keep in mind that Linux machines may use the policy settings in ways that were not intended by the AD admin. For example, it would be problematic if a local admin decided to map "login" to NetworkLogonRight, or if some local admins mapped "ftp" to some LogonRight (but other local admins stayed with the default). This would result in inconsistent behavior between different Linux machines, and between Linux machines and Windows machines. Indeed, in the Windows world, the "local" per-machine GPO is given least priority in case of conflict (i.e. ou overrides domain, which overrides site, which overrides local). A solution to this problem of consistency would be to have a centralized GPO that maps pam services to LogonRights, but I don't think we need to implement that in the first release.
I think limiting ourselves to InteractiveLogonRight and RemoteInteractiveLogonRight would be less confusing and more predictable for AD admins (resulting in a greater likelihood of them deploying gpo-based access control). They would know that these two LogonRights would be enforced with the same semantics on Windows and Linux machines. They would also know that other LogonRights would not be enforced on Linux machines. Clean and crisp.
What do you think?
You make a good argument, but I am not entirely convinced you can avoid a local mapping unless you provide a GPO mapping, because the admin must be able to adjust mappings for new services installed on the box that were not included in the upstream provided lists.
So if you already need to provide a way to augment mappings, you may as well handle all rights with reasonable defaults, and let the admin decide whether they need to change stuff around.
Simo.
Allowing local admins to change stuff from underneath the AD admin's directives seems to violate the GPO philosophy of centralized, consistent application of policy. I don't think AD admins will find the gpo-based access control feature compelling, if it does not fit with their mental model of how GPO is supposed to work.
Sorry but I do not buy this argument. The whole GPO policy can be turned on or off in sssd, so if admins do not control the boxes' sssd.conf file they already know their policies are, at best, advisory.
As you know, LogonRights are existing Windows policy settings (not Linux-specific settings), so we really do have to honor the intent of the settings and the GPO framework.
Indeed, and in order to do that you need to be able to appropriately map arbitrary services.
Having said that, I don't think we necessarily need to have a comprehensive implementation in the first release, especially if we think the GPO mapping is the correct solution (and if we think that we may implement that in a subsequent release).
We do not need the support as a GPO deliverable policy, but you need a local mapping for the feature to be usable/testable IMO.
I think the centralized mapping offered by a future GPO mapping would certainly allay the concerns of AD admins, as the power would remain in their hands and it would be applied consistently. Implementing local mapping now, and then adding a centralized mapping later would delay deployment and would add too much complexity IMO.
Why ? This is exactly the same as overlaying global policy on top of local policy, I honestly do not see it as any more complex than needed.
As for how to deal with new services (in the initial implementation), two ideas come to mind:
- My preference would be that only services included in the upstream
provided lists will be affected by gpo-based access control. Not very extensible, but that's OK if we intend on adding a GPO mapping in a future release.
Upstream runs on multiple OSs and Linux distributions, within those there is already, I bet, enough conflict to make a single upstream list unfeasible, as pam service names are somewhat arbitrary and customized in different way especially for very distro-specific services like login and graphical session managers.
- Alternatively, we could go with a completely different proposal
that would affect all pam services. Specifically, since remote login seems to be an uncommon pam service (we could only come up with "ssh"), we could declare that "ssh" maps to RemoteInteractiveLogonRight, and that *all* other services (including new services, custom services, etc), map to InteractiveLogonRight.
That would be wrong. I suspect one of the services you really want to control, as a windows admin, is samba file services, and those must be mapped to NetworkLogonRight. And NEtworkLogonRight seem to be generally the most sensible default once you exclude the services you know are interactive login shells.
While certainly not ideal (and not my preference), I think AD admins would find this easier to grok than local mappings, as it would be predictable and would allow policy authority to remain centralized, without central directives being manipulated by local admins.
If the admin doesn't grok what services run on a Linux box, they are already doomed I would think. You need at least a passing understanding of the policies you are going to set. We can *definitely* provide a good default set, admins should not be required to provide explicit mappings if the default works for them, but an unchangeable list will severely reduce the utility of the feature.
OK. I forgot that local admins can disable gpo processing, so although AD admins may want centralized control over all domain computers (whether Windows or Linux), they may not be able to get it with this feature. Whether this will be a show-stopper for them remains to be seen. With that in mind, I agree that it makes sense to allow pam services to be mapped to logon rights.
With regard to the default set of mappings, I propose the following (based on previous emails). login/*dm/su* maps to InteractiveLogonRight ssh maps to RemoteInteractiveLogonRight explicit mappings are honored if the service is still unmapped, map it to NetworkLogonRight
I think we can take a page from FreeIPA's configuration, this is the original list of services we provide by default for HBAC:
sshd ftp su login su-l sudo sudo-i gdm gdm-password kdm
To which later updates added: crond vsftpd proftpd pure-ftpd gssftp
Keep in mind that FreeIPA uses also service groups so all the ftp services are grouped under a ftp group.
I think that we can add crond and samba to the first list and use that as the default list.
A few questions for you:
- Does this list make sense?
Mostly, yes.
- Should there be anything special about the default set, or can an
admin re-map services from the default set (i.e. map "ssh" to NetworkLogonRight)?
I would use the following mappings.
InteractiveLogonRight: su, login, su-l, sudo, sudo-i, gdm, gdm-password, kdm RemoteInteractiveLogonRight: sshd NetworkLogonRight: ftp samba BatchLogonRight (?): crond
I am not sure what to use as default fallback for any service that do not match these.
There is a default "remote" service in Fedora, and there is a "other" service which matches any unrecognized service IIRC.
Maybe we could map unknown stuff to ServiceLogonRight which poorly translates to anything useful on Linux I think.
- Should an admin be able to map a service to NULL (indicating that
they don't want this service to be enforced by GPO policy)
So your suggestion would be the unrecognized services would simply be ignored when it comes to GPO enforcing ?
Simo.
----- Original Message -----
On Tue, 2014-07-01 at 01:50 -0400, Yassir Elley wrote:
----- Original Message -----
On Sat, 2014-06-28 at 18:01 -0400, Yassir Elley wrote:
----- Original Message -----
On Sat, 2014-06-28 at 01:20 -0400, Yassir Elley wrote:
----- Original Message ----- > On Thu, 2014-06-26 at 04:54 -0400, Yassir Elley wrote: > > Hi Simo, > > > > I'd like to wrap up this discussion. I propose that we support > > only > > the InteractiveLogonRight (for the pam services you mentioned: > > "login", "*dm, "su*"), and on the RemoteInteractiveLogonRight > > (for > > the > > "ssh" pam service). We should not support the NetworkLogonRight > > since > > it is difficult to implement. Do you agree with this proposal? > > Well I guess the answer depends on what do you plan to do for pam > services that are not listed ? > Do you always deny access ? Always permit ?
Since we would only support the InteractiveLogonRight and RemoteInteractiveLogonRight, we would always permit access for other pam services (because they would not be governed by gpo-based access control, and this would be clearly documented).
> > I think a more reasonable workaround is to define a default type, > and > a > list of mappings. > > If a PAM service is explicitly mapped you use that Right to > decide, > otherwise the decision falls back to the "default" Right. > Actually the default right could well be actually > NetworkLogonRight > or > InteractiveLogonRight or something else. As long as you can > change > the > mappings locally through some configuration that would allow the > admin > to add mappings according to their needs. Of course strong > guidance > on which mappings should be used for specific type of services > should > be > provided. > > Simo. >
I would prefer an approach which is more predictable for the AD admin. If we limit ourselves to InteractiveLogonRight and RemoteInteractiveLogonRight, the semantics are very clear (console login and remote login), allowing the AD Admin to be confident that any existing or future policy files containing those rights would be applied correctly and consistently, regardless of whether the machine is running Linux or Windows.
Also, I suspect AD admins would not like per-machine service mappings to be enforced, since that would defeat the purpose of enforcing a centralized policy in a consistent manner. When an AD admin made a change to a LogonRight policy setting, he would have to keep in mind that Linux machines may use the policy settings in ways that were not intended by the AD admin. For example, it would be problematic if a local admin decided to map "login" to NetworkLogonRight, or if some local admins mapped "ftp" to some LogonRight (but other local admins stayed with the default). This would result in inconsistent behavior between different Linux machines, and between Linux machines and Windows machines. Indeed, in the Windows world, the "local" per-machine GPO is given least priority in case of conflict (i.e. ou overrides domain, which overrides site, which overrides local). A solution to this problem of consistency would be to have a centralized GPO that maps pam services to LogonRights, but I don't think we need to implement that in the first release.
I think limiting ourselves to InteractiveLogonRight and RemoteInteractiveLogonRight would be less confusing and more predictable for AD admins (resulting in a greater likelihood of them deploying gpo-based access control). They would know that these two LogonRights would be enforced with the same semantics on Windows and Linux machines. They would also know that other LogonRights would not be enforced on Linux machines. Clean and crisp.
What do you think?
You make a good argument, but I am not entirely convinced you can avoid a local mapping unless you provide a GPO mapping, because the admin must be able to adjust mappings for new services installed on the box that were not included in the upstream provided lists.
So if you already need to provide a way to augment mappings, you may as well handle all rights with reasonable defaults, and let the admin decide whether they need to change stuff around.
Simo.
Allowing local admins to change stuff from underneath the AD admin's directives seems to violate the GPO philosophy of centralized, consistent application of policy. I don't think AD admins will find the gpo-based access control feature compelling, if it does not fit with their mental model of how GPO is supposed to work.
Sorry but I do not buy this argument. The whole GPO policy can be turned on or off in sssd, so if admins do not control the boxes' sssd.conf file they already know their policies are, at best, advisory.
As you know, LogonRights are existing Windows policy settings (not Linux-specific settings), so we really do have to honor the intent of the settings and the GPO framework.
Indeed, and in order to do that you need to be able to appropriately map arbitrary services.
Having said that, I don't think we necessarily need to have a comprehensive implementation in the first release, especially if we think the GPO mapping is the correct solution (and if we think that we may implement that in a subsequent release).
We do not need the support as a GPO deliverable policy, but you need a local mapping for the feature to be usable/testable IMO.
I think the centralized mapping offered by a future GPO mapping would certainly allay the concerns of AD admins, as the power would remain in their hands and it would be applied consistently. Implementing local mapping now, and then adding a centralized mapping later would delay deployment and would add too much complexity IMO.
Why ? This is exactly the same as overlaying global policy on top of local policy, I honestly do not see it as any more complex than needed.
As for how to deal with new services (in the initial implementation), two ideas come to mind:
- My preference would be that only services included in the upstream
provided lists will be affected by gpo-based access control. Not very extensible, but that's OK if we intend on adding a GPO mapping in a future release.
Upstream runs on multiple OSs and Linux distributions, within those there is already, I bet, enough conflict to make a single upstream list unfeasible, as pam service names are somewhat arbitrary and customized in different way especially for very distro-specific services like login and graphical session managers.
- Alternatively, we could go with a completely different proposal
that would affect all pam services. Specifically, since remote login seems to be an uncommon pam service (we could only come up with "ssh"), we could declare that "ssh" maps to RemoteInteractiveLogonRight, and that *all* other services (including new services, custom services, etc), map to InteractiveLogonRight.
That would be wrong. I suspect one of the services you really want to control, as a windows admin, is samba file services, and those must be mapped to NetworkLogonRight. And NEtworkLogonRight seem to be generally the most sensible default once you exclude the services you know are interactive login shells.
While certainly not ideal (and not my preference), I think AD admins would find this easier to grok than local mappings, as it would be predictable and would allow policy authority to remain centralized, without central directives being manipulated by local admins.
If the admin doesn't grok what services run on a Linux box, they are already doomed I would think. You need at least a passing understanding of the policies you are going to set. We can *definitely* provide a good default set, admins should not be required to provide explicit mappings if the default works for them, but an unchangeable list will severely reduce the utility of the feature.
OK. I forgot that local admins can disable gpo processing, so although AD admins may want centralized control over all domain computers (whether Windows or Linux), they may not be able to get it with this feature. Whether this will be a show-stopper for them remains to be seen. With that in mind, I agree that it makes sense to allow pam services to be mapped to logon rights.
With regard to the default set of mappings, I propose the following (based on previous emails). login/*dm/su* maps to InteractiveLogonRight ssh maps to RemoteInteractiveLogonRight explicit mappings are honored if the service is still unmapped, map it to NetworkLogonRight
I think we can take a page from FreeIPA's configuration, this is the original list of services we provide by default for HBAC:
sshd ftp su login su-l sudo sudo-i gdm gdm-password kdm
To which later updates added: crond vsftpd proftpd pure-ftpd gssftp
Keep in mind that FreeIPA uses also service groups so all the ftp services are grouped under a ftp group.
I think that we can add crond and samba to the first list and use that as the default list.
A few questions for you:
- Does this list make sense?
Mostly, yes.
- Should there be anything special about the default set, or can an
admin re-map services from the default set (i.e. map "ssh" to NetworkLogonRight)?
I would use the following mappings.
InteractiveLogonRight: su, login, su-l, sudo, sudo-i, gdm, gdm-password, kdm RemoteInteractiveLogonRight: sshd NetworkLogonRight: ftp samba BatchLogonRight (?): crond
I am not sure what to use as default fallback for any service that do not match these.
There is a default "remote" service in Fedora, and there is a "other" service which matches any unrecognized service IIRC.
Maybe we could map unknown stuff to ServiceLogonRight which poorly translates to anything useful on Linux I think.
- Should an admin be able to map a service to NULL (indicating that
they don't want this service to be enforced by GPO policy)
So your suggestion would be the unrecognized services would simply be ignored when it comes to GPO enforcing ?
Yes. By essentially providing an opt-in model for pam services (with respect to gpo enforcement), we would be requiring someone to make an informed decision about the service-to-Right mapping (rather than for us to make an arbitrary decision). When an unmapped service is encountered, we would emit a log message (so that the admin can add an explicit mapping, if he forgot to add one). I suspect the distros would be savvy enough to pre-populate the sssd.conf file with distro-specific service mappings, but an individual admin using their own custom pam service might need a nudge.
For example, if an admin forgets to explicitly map a custom service (or doesn't even know he needs to), it would be better for him to receive an "unrecognized service" message in the logs (which would hopefully remind him to add an explicit mapping, after giving it some thought), than for us to arbitrarily map the custom service to some default (which might even result in unintended access denials).
This would be in line with the opt-in model we are using for overall gpo-enforcement (b/c the default is "permissive"). An admin would have to intentionally set the mode to "enforcing", and would have to intentionally provide explicit mappings for non-default services (or even to change a default service mapping).
What do you think?
Regards, Yassir.
On Wed, Jul 02, 2014 at 01:45:00AM -0400, Yassir Elley wrote:
----- Original Message -----
On Tue, 2014-07-01 at 01:50 -0400, Yassir Elley wrote:
----- Original Message -----
On Sat, 2014-06-28 at 18:01 -0400, Yassir Elley wrote:
----- Original Message -----
On Sat, 2014-06-28 at 01:20 -0400, Yassir Elley wrote: > > ----- Original Message ----- > > On Thu, 2014-06-26 at 04:54 -0400, Yassir Elley wrote: > > > Hi Simo, > > > > > > I'd like to wrap up this discussion. I propose that we support > > > only > > > the InteractiveLogonRight (for the pam services you mentioned: > > > "login", "*dm, "su*"), and on the RemoteInteractiveLogonRight > > > (for > > > the > > > "ssh" pam service). We should not support the NetworkLogonRight > > > since > > > it is difficult to implement. Do you agree with this proposal? > > > > Well I guess the answer depends on what do you plan to do for pam > > services that are not listed ? > > Do you always deny access ? Always permit ? > > Since we would only support the InteractiveLogonRight and > RemoteInteractiveLogonRight, we would always permit access for > other > pam > services (because they would not be governed by gpo-based access > control, > and this would be clearly documented). > > > > > I think a more reasonable workaround is to define a default type, > > and > > a > > list of mappings. > > > > If a PAM service is explicitly mapped you use that Right to > > decide, > > otherwise the decision falls back to the "default" Right. > > Actually the default right could well be actually > > NetworkLogonRight > > or > > InteractiveLogonRight or something else. As long as you can > > change > > the > > mappings locally through some configuration that would allow the > > admin > > to add mappings according to their needs. Of course strong > > guidance > > on which mappings should be used for specific type of services > > should > > be > > provided. > > > > Simo. > > > > I would prefer an approach which is more predictable for the AD > admin. > If > we limit ourselves to InteractiveLogonRight and > RemoteInteractiveLogonRight, the semantics are very clear (console > login > and remote login), allowing the AD Admin to be confident that any > existing > or future policy files containing those rights would be applied > correctly > and consistently, regardless of whether the machine is running > Linux or > Windows. > > Also, I suspect AD admins would not like per-machine service > mappings > to be > enforced, since that would defeat the purpose of enforcing a > centralized > policy in a consistent manner. When an AD admin made a change to a > LogonRight policy setting, he would have to keep in mind that Linux > machines may use the policy settings in ways that were not intended > by > the > AD admin. For example, it would be problematic if a local admin > decided > to > map "login" to NetworkLogonRight, or if some local admins mapped > "ftp" > to > some LogonRight (but other local admins stayed with the default). > This > would result in inconsistent behavior between different Linux > machines, > and between Linux machines and Windows machines. Indeed, in the > Windows > world, the "local" per-machine GPO is given least priority in case > of > conflict (i.e. ou overrides domain, which overrides site, which > overrides > local). A solution to this problem of consistency would be to have > a > centralized GPO that maps pam services to LogonRights, but I don't > think > we need to implement that in the first release. > > I think limiting ourselves to InteractiveLogonRight and > RemoteInteractiveLogonRight would be less confusing and more > predictable > for AD admins (resulting in a greater likelihood of them deploying > gpo-based access control). They would know that these two > LogonRights > would be enforced with the same semantics on Windows and Linux > machines. > They would also know that other LogonRights would not be enforced > on > Linux > machines. Clean and crisp. > > What do you think?
You make a good argument, but I am not entirely convinced you can avoid a local mapping unless you provide a GPO mapping, because the admin must be able to adjust mappings for new services installed on the box that were not included in the upstream provided lists.
So if you already need to provide a way to augment mappings, you may as well handle all rights with reasonable defaults, and let the admin decide whether they need to change stuff around.
Simo.
Allowing local admins to change stuff from underneath the AD admin's directives seems to violate the GPO philosophy of centralized, consistent application of policy. I don't think AD admins will find the gpo-based access control feature compelling, if it does not fit with their mental model of how GPO is supposed to work.
Sorry but I do not buy this argument. The whole GPO policy can be turned on or off in sssd, so if admins do not control the boxes' sssd.conf file they already know their policies are, at best, advisory.
As you know, LogonRights are existing Windows policy settings (not Linux-specific settings), so we really do have to honor the intent of the settings and the GPO framework.
Indeed, and in order to do that you need to be able to appropriately map arbitrary services.
Having said that, I don't think we necessarily need to have a comprehensive implementation in the first release, especially if we think the GPO mapping is the correct solution (and if we think that we may implement that in a subsequent release).
We do not need the support as a GPO deliverable policy, but you need a local mapping for the feature to be usable/testable IMO.
I think the centralized mapping offered by a future GPO mapping would certainly allay the concerns of AD admins, as the power would remain in their hands and it would be applied consistently. Implementing local mapping now, and then adding a centralized mapping later would delay deployment and would add too much complexity IMO.
Why ? This is exactly the same as overlaying global policy on top of local policy, I honestly do not see it as any more complex than needed.
As for how to deal with new services (in the initial implementation), two ideas come to mind:
- My preference would be that only services included in the upstream
provided lists will be affected by gpo-based access control. Not very extensible, but that's OK if we intend on adding a GPO mapping in a future release.
Upstream runs on multiple OSs and Linux distributions, within those there is already, I bet, enough conflict to make a single upstream list unfeasible, as pam service names are somewhat arbitrary and customized in different way especially for very distro-specific services like login and graphical session managers.
- Alternatively, we could go with a completely different proposal
that would affect all pam services. Specifically, since remote login seems to be an uncommon pam service (we could only come up with "ssh"), we could declare that "ssh" maps to RemoteInteractiveLogonRight, and that *all* other services (including new services, custom services, etc), map to InteractiveLogonRight.
That would be wrong. I suspect one of the services you really want to control, as a windows admin, is samba file services, and those must be mapped to NetworkLogonRight. And NEtworkLogonRight seem to be generally the most sensible default once you exclude the services you know are interactive login shells.
While certainly not ideal (and not my preference), I think AD admins would find this easier to grok than local mappings, as it would be predictable and would allow policy authority to remain centralized, without central directives being manipulated by local admins.
If the admin doesn't grok what services run on a Linux box, they are already doomed I would think. You need at least a passing understanding of the policies you are going to set. We can *definitely* provide a good default set, admins should not be required to provide explicit mappings if the default works for them, but an unchangeable list will severely reduce the utility of the feature.
OK. I forgot that local admins can disable gpo processing, so although AD admins may want centralized control over all domain computers (whether Windows or Linux), they may not be able to get it with this feature. Whether this will be a show-stopper for them remains to be seen. With that in mind, I agree that it makes sense to allow pam services to be mapped to logon rights.
With regard to the default set of mappings, I propose the following (based on previous emails). login/*dm/su* maps to InteractiveLogonRight ssh maps to RemoteInteractiveLogonRight explicit mappings are honored if the service is still unmapped, map it to NetworkLogonRight
I think we can take a page from FreeIPA's configuration, this is the original list of services we provide by default for HBAC:
sshd ftp su login su-l sudo sudo-i gdm gdm-password kdm
To which later updates added: crond vsftpd proftpd pure-ftpd gssftp
Keep in mind that FreeIPA uses also service groups so all the ftp services are grouped under a ftp group.
I think that we can add crond and samba to the first list and use that as the default list.
A few questions for you:
- Does this list make sense?
Mostly, yes.
- Should there be anything special about the default set, or can an
admin re-map services from the default set (i.e. map "ssh" to NetworkLogonRight)?
I would use the following mappings.
InteractiveLogonRight: su, login, su-l, sudo, sudo-i, gdm, gdm-password, kdm RemoteInteractiveLogonRight: sshd NetworkLogonRight: ftp samba BatchLogonRight (?): crond
I am not sure what to use as default fallback for any service that do not match these.
There is a default "remote" service in Fedora, and there is a "other" service which matches any unrecognized service IIRC.
Maybe we could map unknown stuff to ServiceLogonRight which poorly translates to anything useful on Linux I think.
- Should an admin be able to map a service to NULL (indicating that
they don't want this service to be enforced by GPO policy)
So your suggestion would be the unrecognized services would simply be ignored when it comes to GPO enforcing ?
Yes. By essentially providing an opt-in model for pam services (with respect to gpo enforcement), we would be requiring someone to make an informed decision about the service-to-Right mapping (rather than for us to make an arbitrary decision). When an unmapped service is encountered, we would emit a log message (so that the admin can add an explicit mapping, if he forgot to add one). I suspect the distros would be savvy enough to pre-populate the sssd.conf file with distro-specific service mappings, but an individual admin using their own custom pam service might need a nudge.
For example, if an admin forgets to explicitly map a custom service (or doesn't even know he needs to), it would be better for him to receive an "unrecognized service" message in the logs (which would hopefully remind him to add an explicit mapping, after giving it some thought), than for us to arbitrarily map the custom service to some default (which might even result in unintended access denials).
This would be in line with the opt-in model we are using for overall gpo-enforcement (b/c the default is "permissive"). An admin would have to intentionally set the mode to "enforcing", and would have to intentionally provide explicit mappings for non-default services (or even to change a default service mapping).
What do you think?
Explaining on the logs why access to a service was granted or denied is always a good idea. I guess those messages will fell in the audit-messages category but currently SSSD does not treat audit messages specially. Maybe we should start simple and just add an alias to the DEBUG macro called AUDIT? Later on we can start handling them differently than other debug messages but we will already have (at least for newer code) a label in the code where audit information originates.
(Sorry for hijacking this tread, I'll return now to the gpo and services discussion :-)
I'd like to try to summarize the discussion with a hypothetical man page section of new config options:
ad_gpo_map_interactive (string) A comma-separated list of PAM service names for which access control is evaluated with the help of the AD Interactive Logon Right.
Default: su, login, su-l, sudo, sudo-i, gdm, gdm-password, kdm
ad_gpo_map_remote_interactive (string) A comma-separated list of PAM service names for which access control is evaluated with the help of the AD Remote Interactive Logon Right.
Default: sshd
ad_gpo_map_network (string) A comma-separated list of PAM service names for which access control is evaluated with the help of the AD Network Logon Right.
Default: ftp
ad_gpo_map_batch (string) A comma-separated list of PAM service names for which access control is evaluated with the help of the AD Batch Logon Right.
Default: crond
ad_gpo_map_service (string) A comma-separated list of PAM service names for which access control is evaluated with the help of the AD Service Logon Right.
Default: Not set
ad_gpo_default_rights (string) This option defines how access control is evaluated for PAM services which are not explicitly listed in one of the ad_gpo_map_* options. Allowed values are 'interactive', 'remote_interactive', 'network', 'batch' and 'service' to do the evaluation based on the corresponding AD Logon Right. Additionally 'permit' and 'deny' can be used to either always grant or reject access for those PAM services.
Default: deny
bye, Sumit
Regards, Yassir. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
----- Original Message -----
On Wed, Jul 02, 2014 at 01:45:00AM -0400, Yassir Elley wrote:
----- Original Message -----
On Tue, 2014-07-01 at 01:50 -0400, Yassir Elley wrote:
----- Original Message -----
On Sat, 2014-06-28 at 18:01 -0400, Yassir Elley wrote:
----- Original Message ----- > On Sat, 2014-06-28 at 01:20 -0400, Yassir Elley wrote: > > > > ----- Original Message ----- > > > On Thu, 2014-06-26 at 04:54 -0400, Yassir Elley wrote: > > > > Hi Simo, > > > > > > > > I'd like to wrap up this discussion. I propose that we > > > > support > > > > only > > > > the InteractiveLogonRight (for the pam services you > > > > mentioned: > > > > "login", "*dm, "su*"), and on the > > > > RemoteInteractiveLogonRight > > > > (for > > > > the > > > > "ssh" pam service). We should not support the > > > > NetworkLogonRight > > > > since > > > > it is difficult to implement. Do you agree with this > > > > proposal? > > > > > > Well I guess the answer depends on what do you plan to do for > > > pam > > > services that are not listed ? > > > Do you always deny access ? Always permit ? > > > > Since we would only support the InteractiveLogonRight and > > RemoteInteractiveLogonRight, we would always permit access for > > other > > pam > > services (because they would not be governed by gpo-based > > access > > control, > > and this would be clearly documented). > > > > > > > > I think a more reasonable workaround is to define a default > > > type, > > > and > > > a > > > list of mappings. > > > > > > If a PAM service is explicitly mapped you use that Right to > > > decide, > > > otherwise the decision falls back to the "default" Right. > > > Actually the default right could well be actually > > > NetworkLogonRight > > > or > > > InteractiveLogonRight or something else. As long as you can > > > change > > > the > > > mappings locally through some configuration that would allow > > > the > > > admin > > > to add mappings according to their needs. Of course strong > > > guidance > > > on which mappings should be used for specific type of > > > services > > > should > > > be > > > provided. > > > > > > Simo. > > > > > > > I would prefer an approach which is more predictable for the AD > > admin. > > If > > we limit ourselves to InteractiveLogonRight and > > RemoteInteractiveLogonRight, the semantics are very clear > > (console > > login > > and remote login), allowing the AD Admin to be confident that > > any > > existing > > or future policy files containing those rights would be applied > > correctly > > and consistently, regardless of whether the machine is running > > Linux or > > Windows. > > > > Also, I suspect AD admins would not like per-machine service > > mappings > > to be > > enforced, since that would defeat the purpose of enforcing a > > centralized > > policy in a consistent manner. When an AD admin made a change > > to a > > LogonRight policy setting, he would have to keep in mind that > > Linux > > machines may use the policy settings in ways that were not > > intended > > by > > the > > AD admin. For example, it would be problematic if a local admin > > decided > > to > > map "login" to NetworkLogonRight, or if some local admins > > mapped > > "ftp" > > to > > some LogonRight (but other local admins stayed with the > > default). > > This > > would result in inconsistent behavior between different Linux > > machines, > > and between Linux machines and Windows machines. Indeed, in the > > Windows > > world, the "local" per-machine GPO is given least priority in > > case > > of > > conflict (i.e. ou overrides domain, which overrides site, which > > overrides > > local). A solution to this problem of consistency would be to > > have > > a > > centralized GPO that maps pam services to LogonRights, but I > > don't > > think > > we need to implement that in the first release. > > > > I think limiting ourselves to InteractiveLogonRight and > > RemoteInteractiveLogonRight would be less confusing and more > > predictable > > for AD admins (resulting in a greater likelihood of them > > deploying > > gpo-based access control). They would know that these two > > LogonRights > > would be enforced with the same semantics on Windows and Linux > > machines. > > They would also know that other LogonRights would not be > > enforced > > on > > Linux > > machines. Clean and crisp. > > > > What do you think? > > You make a good argument, but I am not entirely convinced you can > avoid > a local mapping unless you provide a GPO mapping, because the > admin > must > be able to adjust mappings for new services installed on the box > that > were not included in the upstream provided lists. > > So if you already need to provide a way to augment mappings, you > may > as > well handle all rights with reasonable defaults, and let the > admin > decide whether they need to change stuff around. > > Simo. >
Allowing local admins to change stuff from underneath the AD admin's directives seems to violate the GPO philosophy of centralized, consistent application of policy. I don't think AD admins will find the gpo-based access control feature compelling, if it does not fit with their mental model of how GPO is supposed to work.
Sorry but I do not buy this argument. The whole GPO policy can be turned on or off in sssd, so if admins do not control the boxes' sssd.conf file they already know their policies are, at best, advisory.
As you know, LogonRights are existing Windows policy settings (not Linux-specific settings), so we really do have to honor the intent of the settings and the GPO framework.
Indeed, and in order to do that you need to be able to appropriately map arbitrary services.
Having said that, I don't think we necessarily need to have a comprehensive implementation in the first release, especially if we think the GPO mapping is the correct solution (and if we think that we may implement that in a subsequent release).
We do not need the support as a GPO deliverable policy, but you need a local mapping for the feature to be usable/testable IMO.
I think the centralized mapping offered by a future GPO mapping would certainly allay the concerns of AD admins, as the power would remain in their hands and it would be applied consistently. Implementing local mapping now, and then adding a centralized mapping later would delay deployment and would add too much complexity IMO.
Why ? This is exactly the same as overlaying global policy on top of local policy, I honestly do not see it as any more complex than needed.
As for how to deal with new services (in the initial implementation), two ideas come to mind:
- My preference would be that only services included in the
upstream provided lists will be affected by gpo-based access control. Not very extensible, but that's OK if we intend on adding a GPO mapping in a future release.
Upstream runs on multiple OSs and Linux distributions, within those there is already, I bet, enough conflict to make a single upstream list unfeasible, as pam service names are somewhat arbitrary and customized in different way especially for very distro-specific services like login and graphical session managers.
- Alternatively, we could go with a completely different proposal
that would affect all pam services. Specifically, since remote login seems to be an uncommon pam service (we could only come up with "ssh"), we could declare that "ssh" maps to RemoteInteractiveLogonRight, and that *all* other services (including new services, custom services, etc), map to InteractiveLogonRight.
That would be wrong. I suspect one of the services you really want to control, as a windows admin, is samba file services, and those must be mapped to NetworkLogonRight. And NEtworkLogonRight seem to be generally the most sensible default once you exclude the services you know are interactive login shells.
While certainly not ideal (and not my preference), I think AD admins would find this easier to grok than local mappings, as it would be predictable and would allow policy authority to remain centralized, without central directives being manipulated by local admins.
If the admin doesn't grok what services run on a Linux box, they are already doomed I would think. You need at least a passing understanding of the policies you are going to set. We can *definitely* provide a good default set, admins should not be required to provide explicit mappings if the default works for them, but an unchangeable list will severely reduce the utility of the feature.
OK. I forgot that local admins can disable gpo processing, so although AD admins may want centralized control over all domain computers (whether Windows or Linux), they may not be able to get it with this feature. Whether this will be a show-stopper for them remains to be seen. With that in mind, I agree that it makes sense to allow pam services to be mapped to logon rights.
With regard to the default set of mappings, I propose the following (based on previous emails). login/*dm/su* maps to InteractiveLogonRight ssh maps to RemoteInteractiveLogonRight explicit mappings are honored if the service is still unmapped, map it to NetworkLogonRight
I think we can take a page from FreeIPA's configuration, this is the original list of services we provide by default for HBAC:
sshd ftp su login su-l sudo sudo-i gdm gdm-password kdm
To which later updates added: crond vsftpd proftpd pure-ftpd gssftp
Keep in mind that FreeIPA uses also service groups so all the ftp services are grouped under a ftp group.
I think that we can add crond and samba to the first list and use that as the default list.
A few questions for you:
- Does this list make sense?
Mostly, yes.
- Should there be anything special about the default set, or can an
admin re-map services from the default set (i.e. map "ssh" to NetworkLogonRight)?
I would use the following mappings.
InteractiveLogonRight: su, login, su-l, sudo, sudo-i, gdm, gdm-password, kdm RemoteInteractiveLogonRight: sshd NetworkLogonRight: ftp samba BatchLogonRight (?): crond
I am not sure what to use as default fallback for any service that do not match these.
There is a default "remote" service in Fedora, and there is a "other" service which matches any unrecognized service IIRC.
Maybe we could map unknown stuff to ServiceLogonRight which poorly translates to anything useful on Linux I think.
- Should an admin be able to map a service to NULL (indicating that
they don't want this service to be enforced by GPO policy)
So your suggestion would be the unrecognized services would simply be ignored when it comes to GPO enforcing ?
Yes. By essentially providing an opt-in model for pam services (with respect to gpo enforcement), we would be requiring someone to make an informed decision about the service-to-Right mapping (rather than for us to make an arbitrary decision). When an unmapped service is encountered, we would emit a log message (so that the admin can add an explicit mapping, if he forgot to add one). I suspect the distros would be savvy enough to pre-populate the sssd.conf file with distro-specific service mappings, but an individual admin using their own custom pam service might need a nudge.
For example, if an admin forgets to explicitly map a custom service (or doesn't even know he needs to), it would be better for him to receive an "unrecognized service" message in the logs (which would hopefully remind him to add an explicit mapping, after giving it some thought), than for us to arbitrarily map the custom service to some default (which might even result in unintended access denials).
This would be in line with the opt-in model we are using for overall gpo-enforcement (b/c the default is "permissive"). An admin would have to intentionally set the mode to "enforcing", and would have to intentionally provide explicit mappings for non-default services (or even to change a default service mapping).
What do you think?
Explaining on the logs why access to a service was granted or denied is always a good idea. I guess those messages will fell in the audit-messages category but currently SSSD does not treat audit messages specially. Maybe we should start simple and just add an alias to the DEBUG macro called AUDIT? Later on we can start handling them differently than other debug messages but we will already have (at least for newer code) a label in the code where audit information originates.
Can't we just use the sss_log_ext() function that I introduced recently (in util.h). It is currently used only in ad_gpo.c (to deal with gpo permissive mode). Note that this function emits a syslog message to the security log (with or without journald). It does not emit a message to the debug log (although the code separately emits a debug log message).
from ad_gpo.c: sss_log_ext(SSS_LOG_WARNING, LOG_AUTHPRIV, "Warning: user would " \ "have been denied GPO-based logon access if the " \ "ad_gpo_access_control option were set to enforcing " \ "mode.");
(Sorry for hijacking this tread, I'll return now to the gpo and services discussion :-)
I'd like to try to summarize the discussion with a hypothetical man page section of new config options:
ad_gpo_map_interactive (string) A comma-separated list of PAM service names for which access control is evaluated with the help of the AD Interactive Logon Right.
Default: su, login, su-l, sudo, sudo-i, gdm, gdm-password, kdmad_gpo_map_remote_interactive (string) A comma-separated list of PAM service names for which access control is evaluated with the help of the AD Remote Interactive Logon Right.
Default: sshdad_gpo_map_network (string) A comma-separated list of PAM service names for which access control is evaluated with the help of the AD Network Logon Right.
Default: ftpad_gpo_map_batch (string) A comma-separated list of PAM service names for which access control is evaluated with the help of the AD Batch Logon Right.
Default: crondad_gpo_map_service (string) A comma-separated list of PAM service names for which access control is evaluated with the help of the AD Service Logon Right.
Default: Not setad_gpo_default_rights (string) This option defines how access control is evaluated for PAM services which are not explicitly listed in one of the ad_gpo_map_* options. Allowed values are 'interactive', 'remote_interactive', 'network', 'batch' and 'service' to do the evaluation based on the corresponding AD Logon Right. Additionally 'permit' and 'deny' can be used to either always grant or reject access for those PAM services.
Default: denybye, Sumit
Thanks!! This is a great start! Very helpful.
A few comments:
1. We should tweak the wording a bit (and also mention the corresponding Deny Rights). For example, "A comma-separated list of PAM service names for which access control is evaluated based on the AD BatchLogonRight and DenyBatchLogonRight policy settings."
2. We should make the option names describe the contents of the option. For example, "ad_gpo_service_names_interactive"
3. The default for ad_gpo_map_network should also include "samba" (in addition to "ftp")
4. Should we add the various gdm-* service names as interactive: gdm-autologin, gdm-fingerprint, gdm-launch-environment, gdm-pin, gdm-smartcard
5. Should we add the screen savers as interactive: gnome-screensaver, kscreensaver
6. I don't like overloading the ad_gpo_default_rights option so as to include either a Right or a permit/deny. In fact, I don't think a default Right is needed at all (but the permit/deny might be useful). Assuming there are only a handful of unrecognized rights, there is already a convenient mechanism to specify explicit mappings. We can use a non-overloaded option that can be used to specify permit/deny semantics for unmapped service names. I think this would be more understandable. For example: "ad_gpo_service_names_unmapped_action (string): This option defines how access control is evaluated for PAM services which are not explicitly listed in one of the ad_gpo_service_names_* options. Values of 'permit' and 'deny' can be used to either always grant or always reject access for those PAM services."
7. I think the default for the default/unmapped option should be "permit" rather than "deny" (to be consistent with the opt-in model for overall gpo processing)
Comments?
Regards, Yassir
On Thu, Jul 03, 2014 at 01:39:38AM -0400, Yassir Elley wrote:
----- Original Message -----
On Wed, Jul 02, 2014 at 01:45:00AM -0400, Yassir Elley wrote:
----- Original Message -----
On Tue, 2014-07-01 at 01:50 -0400, Yassir Elley wrote:
----- Original Message -----
On Sat, 2014-06-28 at 18:01 -0400, Yassir Elley wrote: > > ----- Original Message ----- > > On Sat, 2014-06-28 at 01:20 -0400, Yassir Elley wrote: > > > > > > ----- Original Message ----- > > > > On Thu, 2014-06-26 at 04:54 -0400, Yassir Elley wrote: > > > > > Hi Simo, > > > > > > > > > > I'd like to wrap up this discussion. I propose that we > > > > > support > > > > > only > > > > > the InteractiveLogonRight (for the pam services you > > > > > mentioned: > > > > > "login", "*dm, "su*"), and on the > > > > > RemoteInteractiveLogonRight > > > > > (for > > > > > the > > > > > "ssh" pam service). We should not support the > > > > > NetworkLogonRight > > > > > since > > > > > it is difficult to implement. Do you agree with this > > > > > proposal? > > > > > > > > Well I guess the answer depends on what do you plan to do for > > > > pam > > > > services that are not listed ? > > > > Do you always deny access ? Always permit ? > > > > > > Since we would only support the InteractiveLogonRight and > > > RemoteInteractiveLogonRight, we would always permit access for > > > other > > > pam > > > services (because they would not be governed by gpo-based > > > access > > > control, > > > and this would be clearly documented). > > > > > > > > > > > I think a more reasonable workaround is to define a default > > > > type, > > > > and > > > > a > > > > list of mappings. > > > > > > > > If a PAM service is explicitly mapped you use that Right to > > > > decide, > > > > otherwise the decision falls back to the "default" Right. > > > > Actually the default right could well be actually > > > > NetworkLogonRight > > > > or > > > > InteractiveLogonRight or something else. As long as you can > > > > change > > > > the > > > > mappings locally through some configuration that would allow > > > > the > > > > admin > > > > to add mappings according to their needs. Of course strong > > > > guidance > > > > on which mappings should be used for specific type of > > > > services > > > > should > > > > be > > > > provided. > > > > > > > > Simo. > > > > > > > > > > I would prefer an approach which is more predictable for the AD > > > admin. > > > If > > > we limit ourselves to InteractiveLogonRight and > > > RemoteInteractiveLogonRight, the semantics are very clear > > > (console > > > login > > > and remote login), allowing the AD Admin to be confident that > > > any > > > existing > > > or future policy files containing those rights would be applied > > > correctly > > > and consistently, regardless of whether the machine is running > > > Linux or > > > Windows. > > > > > > Also, I suspect AD admins would not like per-machine service > > > mappings > > > to be > > > enforced, since that would defeat the purpose of enforcing a > > > centralized > > > policy in a consistent manner. When an AD admin made a change > > > to a > > > LogonRight policy setting, he would have to keep in mind that > > > Linux > > > machines may use the policy settings in ways that were not > > > intended > > > by > > > the > > > AD admin. For example, it would be problematic if a local admin > > > decided > > > to > > > map "login" to NetworkLogonRight, or if some local admins > > > mapped > > > "ftp" > > > to > > > some LogonRight (but other local admins stayed with the > > > default). > > > This > > > would result in inconsistent behavior between different Linux > > > machines, > > > and between Linux machines and Windows machines. Indeed, in the > > > Windows > > > world, the "local" per-machine GPO is given least priority in > > > case > > > of > > > conflict (i.e. ou overrides domain, which overrides site, which > > > overrides > > > local). A solution to this problem of consistency would be to > > > have > > > a > > > centralized GPO that maps pam services to LogonRights, but I > > > don't > > > think > > > we need to implement that in the first release. > > > > > > I think limiting ourselves to InteractiveLogonRight and > > > RemoteInteractiveLogonRight would be less confusing and more > > > predictable > > > for AD admins (resulting in a greater likelihood of them > > > deploying > > > gpo-based access control). They would know that these two > > > LogonRights > > > would be enforced with the same semantics on Windows and Linux > > > machines. > > > They would also know that other LogonRights would not be > > > enforced > > > on > > > Linux > > > machines. Clean and crisp. > > > > > > What do you think? > > > > You make a good argument, but I am not entirely convinced you can > > avoid > > a local mapping unless you provide a GPO mapping, because the > > admin > > must > > be able to adjust mappings for new services installed on the box > > that > > were not included in the upstream provided lists. > > > > So if you already need to provide a way to augment mappings, you > > may > > as > > well handle all rights with reasonable defaults, and let the > > admin > > decide whether they need to change stuff around. > > > > Simo. > > > > Allowing local admins to change stuff from underneath the AD > admin's > directives seems to violate the GPO philosophy of centralized, > consistent application of policy. I don't think AD admins will find > the gpo-based access control feature compelling, if it does not fit > with their mental model of how GPO is supposed to work.
Sorry but I do not buy this argument. The whole GPO policy can be turned on or off in sssd, so if admins do not control the boxes' sssd.conf file they already know their policies are, at best, advisory.
> As you know, LogonRights are existing Windows policy settings (not > Linux-specific settings), so we really do have to honor the intent > of > the settings and the GPO framework.
Indeed, and in order to do that you need to be able to appropriately map arbitrary services.
> Having said that, I don't think we necessarily need to have a > comprehensive implementation in the first release, especially if we > think the GPO mapping is the correct solution (and if we think that > we > may implement that in a subsequent release).
We do not need the support as a GPO deliverable policy, but you need a local mapping for the feature to be usable/testable IMO.
> I think the centralized mapping offered by a future GPO mapping > would > certainly allay the concerns of AD admins, as the power would > remain > in their hands and it would be applied consistently. Implementing > local mapping now, and then adding a centralized mapping later > would > delay deployment and would add too much complexity IMO.
Why ? This is exactly the same as overlaying global policy on top of local policy, I honestly do not see it as any more complex than needed.
> As for how to deal with new services (in the initial > implementation), > two ideas come to mind: > 1) My preference would be that only services included in the > upstream > provided lists will be affected by gpo-based access control. Not > very > extensible, but that's OK if we intend on adding a GPO mapping in a > future release.
Upstream runs on multiple OSs and Linux distributions, within those there is already, I bet, enough conflict to make a single upstream list unfeasible, as pam service names are somewhat arbitrary and customized in different way especially for very distro-specific services like login and graphical session managers.
> 2) Alternatively, we could go with a completely different proposal > that would affect all pam services. Specifically, since remote > login > seems to be an uncommon pam service (we could only come up with > "ssh"), we could declare that "ssh" maps to > RemoteInteractiveLogonRight, and that *all* other services > (including > new services, custom services, etc), map to InteractiveLogonRight.
That would be wrong. I suspect one of the services you really want to control, as a windows admin, is samba file services, and those must be mapped to NetworkLogonRight. And NEtworkLogonRight seem to be generally the most sensible default once you exclude the services you know are interactive login shells.
> While certainly not ideal (and not my preference), I think AD > admins > would find this easier to grok than local mappings, as it would be > predictable and would allow policy authority to remain centralized, > without central directives being manipulated by local admins.
If the admin doesn't grok what services run on a Linux box, they are already doomed I would think. You need at least a passing understanding of the policies you are going to set. We can *definitely* provide a good default set, admins should not be required to provide explicit mappings if the default works for them, but an unchangeable list will severely reduce the utility of the feature.
OK. I forgot that local admins can disable gpo processing, so although AD admins may want centralized control over all domain computers (whether Windows or Linux), they may not be able to get it with this feature. Whether this will be a show-stopper for them remains to be seen. With that in mind, I agree that it makes sense to allow pam services to be mapped to logon rights.
With regard to the default set of mappings, I propose the following (based on previous emails). login/*dm/su* maps to InteractiveLogonRight ssh maps to RemoteInteractiveLogonRight explicit mappings are honored if the service is still unmapped, map it to NetworkLogonRight
I think we can take a page from FreeIPA's configuration, this is the original list of services we provide by default for HBAC:
sshd ftp su login su-l sudo sudo-i gdm gdm-password kdm
To which later updates added: crond vsftpd proftpd pure-ftpd gssftp
Keep in mind that FreeIPA uses also service groups so all the ftp services are grouped under a ftp group.
I think that we can add crond and samba to the first list and use that as the default list.
A few questions for you:
- Does this list make sense?
Mostly, yes.
- Should there be anything special about the default set, or can an
admin re-map services from the default set (i.e. map "ssh" to NetworkLogonRight)?
I would use the following mappings.
InteractiveLogonRight: su, login, su-l, sudo, sudo-i, gdm, gdm-password, kdm RemoteInteractiveLogonRight: sshd NetworkLogonRight: ftp samba BatchLogonRight (?): crond
I am not sure what to use as default fallback for any service that do not match these.
There is a default "remote" service in Fedora, and there is a "other" service which matches any unrecognized service IIRC.
Maybe we could map unknown stuff to ServiceLogonRight which poorly translates to anything useful on Linux I think.
- Should an admin be able to map a service to NULL (indicating that
they don't want this service to be enforced by GPO policy)
So your suggestion would be the unrecognized services would simply be ignored when it comes to GPO enforcing ?
Yes. By essentially providing an opt-in model for pam services (with respect to gpo enforcement), we would be requiring someone to make an informed decision about the service-to-Right mapping (rather than for us to make an arbitrary decision). When an unmapped service is encountered, we would emit a log message (so that the admin can add an explicit mapping, if he forgot to add one). I suspect the distros would be savvy enough to pre-populate the sssd.conf file with distro-specific service mappings, but an individual admin using their own custom pam service might need a nudge.
For example, if an admin forgets to explicitly map a custom service (or doesn't even know he needs to), it would be better for him to receive an "unrecognized service" message in the logs (which would hopefully remind him to add an explicit mapping, after giving it some thought), than for us to arbitrarily map the custom service to some default (which might even result in unintended access denials).
This would be in line with the opt-in model we are using for overall gpo-enforcement (b/c the default is "permissive"). An admin would have to intentionally set the mode to "enforcing", and would have to intentionally provide explicit mappings for non-default services (or even to change a default service mapping).
What do you think?
Explaining on the logs why access to a service was granted or denied is always a good idea. I guess those messages will fell in the audit-messages category but currently SSSD does not treat audit messages specially. Maybe we should start simple and just add an alias to the DEBUG macro called AUDIT? Later on we can start handling them differently than other debug messages but we will already have (at least for newer code) a label in the code where audit information originates.
Can't we just use the sss_log_ext() function that I introduced recently (in util.h). It is currently used only in ad_gpo.c (to deal with gpo permissive mode). Note that this function emits a syslog message to the security log (with or without journald). It does not emit a message to the debug log (although the code separately emits a debug log message).
from ad_gpo.c: sss_log_ext(SSS_LOG_WARNING, LOG_AUTHPRIV, "Warning: user would " \ "have been denied GPO-based logon access if the " \ "ad_gpo_access_control option were set to enforcing " \ "mode.");
sure, having it in the syslog/journal might be even better then in the SSSD logs. My point is to make it clear that it is an audit message and not just a warning or error messages.
(Sorry for hijacking this tread, I'll return now to the gpo and services discussion :-)
I'd like to try to summarize the discussion with a hypothetical man page section of new config options:
ad_gpo_map_interactive (string) A comma-separated list of PAM service names for which access control is evaluated with the help of the AD Interactive Logon Right.
Default: su, login, su-l, sudo, sudo-i, gdm, gdm-password, kdmad_gpo_map_remote_interactive (string) A comma-separated list of PAM service names for which access control is evaluated with the help of the AD Remote Interactive Logon Right.
Default: sshdad_gpo_map_network (string) A comma-separated list of PAM service names for which access control is evaluated with the help of the AD Network Logon Right.
Default: ftpad_gpo_map_batch (string) A comma-separated list of PAM service names for which access control is evaluated with the help of the AD Batch Logon Right.
Default: crondad_gpo_map_service (string) A comma-separated list of PAM service names for which access control is evaluated with the help of the AD Service Logon Right.
Default: Not setad_gpo_default_rights (string) This option defines how access control is evaluated for PAM services which are not explicitly listed in one of the ad_gpo_map_* options. Allowed values are 'interactive', 'remote_interactive', 'network', 'batch' and 'service' to do the evaluation based on the corresponding AD Logon Right. Additionally 'permit' and 'deny' can be used to either always grant or reject access for those PAM services.
Default: denybye, Sumit
Thanks!! This is a great start! Very helpful.
A few comments:
We should tweak the wording a bit (and also mention the corresponding Deny Rights). For example, "A comma-separated list of PAM service names for which access control is evaluated based on the AD BatchLogonRight and DenyBatchLogonRight policy settings."
We should make the option names describe the contents of the option. For example, "ad_gpo_service_names_interactive"
sure, feel free to improve this, it is just a first suggestion.
- The default for ad_gpo_map_network should also include "samba" (in addition to "ftp")
I'm not aware of a "samba" PAM service.
Should we add the various gdm-* service names as interactive: gdm-autologin, gdm-fingerprint, gdm-launch-environment, gdm-pin, gdm-smartcard
Should we add the screen savers as interactive: gnome-screensaver, kscreensaver
sure, I'm not sure if some of the gdm-* option are Fedora/RHEL specific, but even if it is it won't hurt on other distributions.
- I don't like overloading the ad_gpo_default_rights option so as to include either a Right or a permit/deny. In fact, I don't think a default Right is needed at all (but the permit/deny might be useful). Assuming there are only a handful of unrecognized rights, there is already a convenient mechanism to specify explicit mappings. We can use a non-overloaded option that can be used to specify permit/deny semantics for unmapped service names. I think this would be more understandable. For example: "ad_gpo_service_names_unmapped_action (string): This option defines how access control is evaluated for PAM services which are not explicitly listed in one of the ad_gpo_service_names_* options. Values of 'permit' and 'deny' can be used to either always grant or always reject access for those PAM services."
I had the following use-case in mind. Since the mapping cannot be managed in AD (yet) admins might want to cover all PAM services in a single right, e.g. BatchLogonRight. To not force the admin to list all PAM servies (the known, the known unknown and the unknown unknown :-) in the BatchLogonRight specific option I thought allow the right in the default option is the nices solution than allowing a catch all like '*' in the right specific options.
- I think the default for the default/unmapped option should be "permit" rather than "deny" (to be consistent with the opt-in model for overall gpo processing)
My thinking here is that access control in SSSD in general is opt-in because the default access provider it 'permit'. If you change this e.g. by activating the IPA access provider you delegate the decision if access is granted or not to an external source. If the external source cannot make a decision it is an error from the SSSD perspective and access should be denied in case of an error.
GPO is special here, because the external source cannot decide on its own but needs the local PAM service mapping as well. But I still think 'deny' is a good default because it will help to faster recognise that there is an unconfigured PAM service.
bye, Sumit
Comments?
Regards, Yassir _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
----- Original Message -----
On Thu, Jul 03, 2014 at 01:39:38AM -0400, Yassir Elley wrote:
----- Original Message -----
On Wed, Jul 02, 2014 at 01:45:00AM -0400, Yassir Elley wrote:
----- Original Message -----
On Tue, 2014-07-01 at 01:50 -0400, Yassir Elley wrote:
----- Original Message ----- > On Sat, 2014-06-28 at 18:01 -0400, Yassir Elley wrote: > > > > ----- Original Message ----- > > > On Sat, 2014-06-28 at 01:20 -0400, Yassir Elley wrote: > > > > > > > > ----- Original Message ----- > > > > > On Thu, 2014-06-26 at 04:54 -0400, Yassir Elley wrote: > > > > > > Hi Simo, > > > > > > > > > > > > I'd like to wrap up this discussion. I propose that we > > > > > > support > > > > > > only > > > > > > the InteractiveLogonRight (for the pam services you > > > > > > mentioned: > > > > > > "login", "*dm, "su*"), and on the > > > > > > RemoteInteractiveLogonRight > > > > > > (for > > > > > > the > > > > > > "ssh" pam service). We should not support the > > > > > > NetworkLogonRight > > > > > > since > > > > > > it is difficult to implement. Do you agree with this > > > > > > proposal? > > > > > > > > > > Well I guess the answer depends on what do you plan to do > > > > > for > > > > > pam > > > > > services that are not listed ? > > > > > Do you always deny access ? Always permit ? > > > > > > > > Since we would only support the InteractiveLogonRight and > > > > RemoteInteractiveLogonRight, we would always permit access > > > > for > > > > other > > > > pam > > > > services (because they would not be governed by gpo-based > > > > access > > > > control, > > > > and this would be clearly documented). > > > > > > > > > > > > > > I think a more reasonable workaround is to define a > > > > > default > > > > > type, > > > > > and > > > > > a > > > > > list of mappings. > > > > > > > > > > If a PAM service is explicitly mapped you use that Right > > > > > to > > > > > decide, > > > > > otherwise the decision falls back to the "default" Right. > > > > > Actually the default right could well be actually > > > > > NetworkLogonRight > > > > > or > > > > > InteractiveLogonRight or something else. As long as you > > > > > can > > > > > change > > > > > the > > > > > mappings locally through some configuration that would > > > > > allow > > > > > the > > > > > admin > > > > > to add mappings according to their needs. Of course > > > > > strong > > > > > guidance > > > > > on which mappings should be used for specific type of > > > > > services > > > > > should > > > > > be > > > > > provided. > > > > > > > > > > Simo. > > > > > > > > > > > > > I would prefer an approach which is more predictable for > > > > the AD > > > > admin. > > > > If > > > > we limit ourselves to InteractiveLogonRight and > > > > RemoteInteractiveLogonRight, the semantics are very clear > > > > (console > > > > login > > > > and remote login), allowing the AD Admin to be confident > > > > that > > > > any > > > > existing > > > > or future policy files containing those rights would be > > > > applied > > > > correctly > > > > and consistently, regardless of whether the machine is > > > > running > > > > Linux or > > > > Windows. > > > > > > > > Also, I suspect AD admins would not like per-machine > > > > service > > > > mappings > > > > to be > > > > enforced, since that would defeat the purpose of enforcing > > > > a > > > > centralized > > > > policy in a consistent manner. When an AD admin made a > > > > change > > > > to a > > > > LogonRight policy setting, he would have to keep in mind > > > > that > > > > Linux > > > > machines may use the policy settings in ways that were not > > > > intended > > > > by > > > > the > > > > AD admin. For example, it would be problematic if a local > > > > admin > > > > decided > > > > to > > > > map "login" to NetworkLogonRight, or if some local admins > > > > mapped > > > > "ftp" > > > > to > > > > some LogonRight (but other local admins stayed with the > > > > default). > > > > This > > > > would result in inconsistent behavior between different > > > > Linux > > > > machines, > > > > and between Linux machines and Windows machines. Indeed, in > > > > the > > > > Windows > > > > world, the "local" per-machine GPO is given least priority > > > > in > > > > case > > > > of > > > > conflict (i.e. ou overrides domain, which overrides site, > > > > which > > > > overrides > > > > local). A solution to this problem of consistency would be > > > > to > > > > have > > > > a > > > > centralized GPO that maps pam services to LogonRights, but > > > > I > > > > don't > > > > think > > > > we need to implement that in the first release. > > > > > > > > I think limiting ourselves to InteractiveLogonRight and > > > > RemoteInteractiveLogonRight would be less confusing and > > > > more > > > > predictable > > > > for AD admins (resulting in a greater likelihood of them > > > > deploying > > > > gpo-based access control). They would know that these two > > > > LogonRights > > > > would be enforced with the same semantics on Windows and > > > > Linux > > > > machines. > > > > They would also know that other LogonRights would not be > > > > enforced > > > > on > > > > Linux > > > > machines. Clean and crisp. > > > > > > > > What do you think? > > > > > > You make a good argument, but I am not entirely convinced you > > > can > > > avoid > > > a local mapping unless you provide a GPO mapping, because the > > > admin > > > must > > > be able to adjust mappings for new services installed on the > > > box > > > that > > > were not included in the upstream provided lists. > > > > > > So if you already need to provide a way to augment mappings, > > > you > > > may > > > as > > > well handle all rights with reasonable defaults, and let the > > > admin > > > decide whether they need to change stuff around. > > > > > > Simo. > > > > > > > Allowing local admins to change stuff from underneath the AD > > admin's > > directives seems to violate the GPO philosophy of centralized, > > consistent application of policy. I don't think AD admins will > > find > > the gpo-based access control feature compelling, if it does not > > fit > > with their mental model of how GPO is supposed to work. > > Sorry but I do not buy this argument. The whole GPO policy can be > turned > on or off in sssd, so if admins do not control the boxes' > sssd.conf > file > they already know their policies are, at best, advisory. > > > As you know, LogonRights are existing Windows policy settings > > (not > > Linux-specific settings), so we really do have to honor the > > intent > > of > > the settings and the GPO framework. > > Indeed, and in order to do that you need to be able to > appropriately > map > arbitrary services. > > > Having said that, I don't think we necessarily need to have a > > comprehensive implementation in the first release, especially > > if we > > think the GPO mapping is the correct solution (and if we think > > that > > we > > may implement that in a subsequent release). > > We do not need the support as a GPO deliverable policy, but you > need > a > local mapping for the feature to be usable/testable IMO. > > > I think the centralized mapping offered by a future GPO mapping > > would > > certainly allay the concerns of AD admins, as the power would > > remain > > in their hands and it would be applied consistently. > > Implementing > > local mapping now, and then adding a centralized mapping later > > would > > delay deployment and would add too much complexity IMO. > > Why ? This is exactly the same as overlaying global policy on top > of > local policy, I honestly do not see it as any more complex than > needed. > > > As for how to deal with new services (in the initial > > implementation), > > two ideas come to mind: > > 1) My preference would be that only services included in the > > upstream > > provided lists will be affected by gpo-based access control. > > Not > > very > > extensible, but that's OK if we intend on adding a GPO mapping > > in a > > future release. > > Upstream runs on multiple OSs and Linux distributions, within > those > there is already, I bet, enough conflict to make a single > upstream > list > unfeasible, as pam service names are somewhat arbitrary and > customized > in different way especially for very distro-specific services > like > login > and graphical session managers. > > > 2) Alternatively, we could go with a completely different > > proposal > > that would affect all pam services. Specifically, since remote > > login > > seems to be an uncommon pam service (we could only come up with > > "ssh"), we could declare that "ssh" maps to > > RemoteInteractiveLogonRight, and that *all* other services > > (including > > new services, custom services, etc), map to > > InteractiveLogonRight. > > That would be wrong. I suspect one of the services you really > want to > control, as a windows admin, is samba file services, and those > must > be > mapped to NetworkLogonRight. > And NEtworkLogonRight seem to be generally the most sensible > default > once you exclude the services you know are interactive login > shells. > > > While certainly not ideal (and not my preference), I think AD > > admins > > would find this easier to grok than local mappings, as it would > > be > > predictable and would allow policy authority to remain > > centralized, > > without central directives being manipulated by local admins. > > If the admin doesn't grok what services run on a Linux box, they > are > already doomed I would think. You need at least a passing > understanding > of the policies you are going to set. We can *definitely* provide > a > good > default set, admins should not be required to provide explicit > mappings > if the default works for them, but an unchangeable list will > severely > reduce the utility of the feature. >
OK. I forgot that local admins can disable gpo processing, so although AD admins may want centralized control over all domain computers (whether Windows or Linux), they may not be able to get it with this feature. Whether this will be a show-stopper for them remains to be seen. With that in mind, I agree that it makes sense to allow pam services to be mapped to logon rights.
With regard to the default set of mappings, I propose the following (based on previous emails). login/*dm/su* maps to InteractiveLogonRight ssh maps to RemoteInteractiveLogonRight explicit mappings are honored if the service is still unmapped, map it to NetworkLogonRight
I think we can take a page from FreeIPA's configuration, this is the original list of services we provide by default for HBAC:
sshd ftp su login su-l sudo sudo-i gdm gdm-password kdm
To which later updates added: crond vsftpd proftpd pure-ftpd gssftp
Keep in mind that FreeIPA uses also service groups so all the ftp services are grouped under a ftp group.
I think that we can add crond and samba to the first list and use that as the default list.
A few questions for you:
- Does this list make sense?
Mostly, yes.
- Should there be anything special about the default set, or can an
admin re-map services from the default set (i.e. map "ssh" to NetworkLogonRight)?
I would use the following mappings.
InteractiveLogonRight: su, login, su-l, sudo, sudo-i, gdm, gdm-password, kdm RemoteInteractiveLogonRight: sshd NetworkLogonRight: ftp samba BatchLogonRight (?): crond
I am not sure what to use as default fallback for any service that do not match these.
There is a default "remote" service in Fedora, and there is a "other" service which matches any unrecognized service IIRC.
Maybe we could map unknown stuff to ServiceLogonRight which poorly translates to anything useful on Linux I think.
- Should an admin be able to map a service to NULL (indicating that
they don't want this service to be enforced by GPO policy)
So your suggestion would be the unrecognized services would simply be ignored when it comes to GPO enforcing ?
Yes. By essentially providing an opt-in model for pam services (with respect to gpo enforcement), we would be requiring someone to make an informed decision about the service-to-Right mapping (rather than for us to make an arbitrary decision). When an unmapped service is encountered, we would emit a log message (so that the admin can add an explicit mapping, if he forgot to add one). I suspect the distros would be savvy enough to pre-populate the sssd.conf file with distro-specific service mappings, but an individual admin using their own custom pam service might need a nudge.
For example, if an admin forgets to explicitly map a custom service (or doesn't even know he needs to), it would be better for him to receive an "unrecognized service" message in the logs (which would hopefully remind him to add an explicit mapping, after giving it some thought), than for us to arbitrarily map the custom service to some default (which might even result in unintended access denials).
This would be in line with the opt-in model we are using for overall gpo-enforcement (b/c the default is "permissive"). An admin would have to intentionally set the mode to "enforcing", and would have to intentionally provide explicit mappings for non-default services (or even to change a default service mapping).
What do you think?
Explaining on the logs why access to a service was granted or denied is always a good idea. I guess those messages will fell in the audit-messages category but currently SSSD does not treat audit messages specially. Maybe we should start simple and just add an alias to the DEBUG macro called AUDIT? Later on we can start handling them differently than other debug messages but we will already have (at least for newer code) a label in the code where audit information originates.
Can't we just use the sss_log_ext() function that I introduced recently (in util.h). It is currently used only in ad_gpo.c (to deal with gpo permissive mode). Note that this function emits a syslog message to the security log (with or without journald). It does not emit a message to the debug log (although the code separately emits a debug log message).
from ad_gpo.c: sss_log_ext(SSS_LOG_WARNING, LOG_AUTHPRIV, "Warning: user would " \ "have been denied GPO-based logon access if the " \ "ad_gpo_access_control option were set to enforcing " \ "mode.");
sure, having it in the syslog/journal might be even better then in the SSSD logs. My point is to make it clear that it is an audit message and not just a warning or error messages.
How are you defining "audit message"? Does it mean a status message that doesn't mean anything is wrong (no warning, no error), but that it would be useful for the admin to know?
(Sorry for hijacking this tread, I'll return now to the gpo and services discussion :-)
I'd like to try to summarize the discussion with a hypothetical man page section of new config options:
ad_gpo_map_interactive (string) A comma-separated list of PAM service names for which access control is evaluated with the help of the AD Interactive Logon Right.
Default: su, login, su-l, sudo, sudo-i, gdm, gdm-password, kdmad_gpo_map_remote_interactive (string) A comma-separated list of PAM service names for which access control is evaluated with the help of the AD Remote Interactive Logon Right.
Default: sshdad_gpo_map_network (string) A comma-separated list of PAM service names for which access control is evaluated with the help of the AD Network Logon Right.
Default: ftpad_gpo_map_batch (string) A comma-separated list of PAM service names for which access control is evaluated with the help of the AD Batch Logon Right.
Default: crondad_gpo_map_service (string) A comma-separated list of PAM service names for which access control is evaluated with the help of the AD Service Logon Right.
Default: Not setad_gpo_default_rights (string) This option defines how access control is evaluated for PAM services which are not explicitly listed in one of the ad_gpo_map_* options. Allowed values are 'interactive', 'remote_interactive', 'network', 'batch' and 'service' to do the evaluation based on the corresponding AD Logon Right. Additionally 'permit' and 'deny' can be used to either always grant or reject access for those PAM services.
Default: denybye, Sumit
Thanks!! This is a great start! Very helpful.
A few comments:
- We should tweak the wording a bit (and also mention the corresponding
Deny Rights). For example, "A comma-separated list of PAM service names for which access control is evaluated based on the AD BatchLogonRight and DenyBatchLogonRight policy settings."
- We should make the option names describe the contents of the option. For
example, "ad_gpo_service_names_interactive"
sure, feel free to improve this, it is just a first suggestion.
- The default for ad_gpo_map_network should also include "samba" (in
addition to "ftp")
I'm not aware of a "samba" PAM service.
I think Simo suggested adding the "samba" PAM service to NetworkLogonRight. Simo, can you clarify what you meant?
- Should we add the various gdm-* service names as interactive:
gdm-autologin, gdm-fingerprint, gdm-launch-environment, gdm-pin, gdm-smartcard
- Should we add the screen savers as interactive: gnome-screensaver,
kscreensaver
sure, I'm not sure if some of the gdm-* option are Fedora/RHEL specific, but even if it is it won't hurt on other distributions.
- I don't like overloading the ad_gpo_default_rights option so as to
include either a Right or a permit/deny. In fact, I don't think a default Right is needed at all (but the permit/deny might be useful). Assuming there are only a handful of unrecognized rights, there is already a convenient mechanism to specify explicit mappings. We can use a non-overloaded option that can be used to specify permit/deny semantics for unmapped service names. I think this would be more understandable. For example: "ad_gpo_service_names_unmapped_action (string): This option defines how access control is evaluated for PAM services which are not explicitly listed in one of the ad_gpo_service_names_* options. Values of 'permit' and 'deny' can be used to either always grant or always reject access for those PAM services."
I had the following use-case in mind. Since the mapping cannot be managed in AD (yet) admins might want to cover all PAM services in a single right, e.g. BatchLogonRight. To not force the admin to list all PAM servies (the known, the known unknown and the unknown unknown :-) in the BatchLogonRight specific option I thought allow the right in the default option is the nices solution than allowing a catch all like '*' in the right specific options.
I think this could be useful, although, with wildcards, admins may just pick an arbitrary right as the default right (i.e. they may not be forced to think about which right does this service name really correspond to, which they would have had to do if we required explicit mappings). My primary objection to this proposal was in overloading the ad_gpo_default_rights option, which could take the name of a Right as a value, or a permit/deny as a value. This seems unusual. Do we do it anywhere else in sssd?
Perhaps, we could just split ad_gpo_default_rights option into two options, and it would be an error to set both options. Maybe: * "ad_gpo_default_right" takes the name of a right ("interactive", "network", etc) as a value * "ad_gpo_service_names_unmapped_action" takes "permit" or "deny" as a value
Or are the number of gpo options already out of control?
- I think the default for the default/unmapped option should be "permit"
rather than "deny" (to be consistent with the opt-in model for overall gpo processing)
My thinking here is that access control in SSSD in general is opt-in because the default access provider it 'permit'. If you change this e.g. by activating the IPA access provider you delegate the decision if access is granted or not to an external source. If the external source cannot make a decision it is an error from the SSSD perspective and access should be denied in case of an error.
GPO is special here, because the external source cannot decide on its own but needs the local PAM service mapping as well. But I still think 'deny' is a good default because it will help to faster recognise that there is an unconfigured PAM service.
OK. Good point. I agree that we should deny by default.
Regards, Yassir.
On Fri, 2014-07-04 at 01:18 -0400, Yassir Elley wrote:
- The default for ad_gpo_map_network should also include
"samba" (in
addition to "ftp")
I'm not aware of a "samba" PAM service.
And yet it exists :)
I think Simo suggested adding the "samba" PAM service to NetworkLogonRight. Simo, can you clarify what you meant?
I meant exactly what you wrote, add samba as oine of the default services mapped to NetworkLogonRight
Simo.
On Thu, Jul 03, 2014 at 01:39:38AM -0400, Yassir Elley wrote:
----- Original Message -----
On Wed, Jul 02, 2014 at 01:45:00AM -0400, Yassir Elley wrote:
----- Original Message -----
On Tue, 2014-07-01 at 01:50 -0400, Yassir Elley wrote:
----- Original Message -----
On Sat, 2014-06-28 at 18:01 -0400, Yassir Elley wrote: > > ----- Original Message ----- > > On Sat, 2014-06-28 at 01:20 -0400, Yassir Elley wrote: > > > > > > ----- Original Message ----- > > > > On Thu, 2014-06-26 at 04:54 -0400, Yassir Elley wrote: > > > > > Hi Simo, > > > > > > > > > > I'd like to wrap up this discussion. I propose that we > > > > > support > > > > > only > > > > > the InteractiveLogonRight (for the pam services you > > > > > mentioned: > > > > > "login", "*dm, "su*"), and on the > > > > > RemoteInteractiveLogonRight > > > > > (for > > > > > the > > > > > "ssh" pam service). We should not support the > > > > > NetworkLogonRight > > > > > since > > > > > it is difficult to implement. Do you agree with this > > > > > proposal? > > > > > > > > Well I guess the answer depends on what do you plan to do for > > > > pam > > > > services that are not listed ? > > > > Do you always deny access ? Always permit ? > > > > > > Since we would only support the InteractiveLogonRight and > > > RemoteInteractiveLogonRight, we would always permit access for > > > other > > > pam > > > services (because they would not be governed by gpo-based > > > access > > > control, > > > and this would be clearly documented). > > > > > > > > > > > I think a more reasonable workaround is to define a default > > > > type, > > > > and > > > > a > > > > list of mappings. > > > > > > > > If a PAM service is explicitly mapped you use that Right to > > > > decide, > > > > otherwise the decision falls back to the "default" Right. > > > > Actually the default right could well be actually > > > > NetworkLogonRight > > > > or > > > > InteractiveLogonRight or something else. As long as you can > > > > change > > > > the > > > > mappings locally through some configuration that would allow > > > > the > > > > admin > > > > to add mappings according to their needs. Of course strong > > > > guidance > > > > on which mappings should be used for specific type of > > > > services > > > > should > > > > be > > > > provided. > > > > > > > > Simo. > > > > > > > > > > I would prefer an approach which is more predictable for the AD > > > admin. > > > If > > > we limit ourselves to InteractiveLogonRight and > > > RemoteInteractiveLogonRight, the semantics are very clear > > > (console > > > login > > > and remote login), allowing the AD Admin to be confident that > > > any > > > existing > > > or future policy files containing those rights would be applied > > > correctly > > > and consistently, regardless of whether the machine is running > > > Linux or > > > Windows. > > > > > > Also, I suspect AD admins would not like per-machine service > > > mappings > > > to be > > > enforced, since that would defeat the purpose of enforcing a > > > centralized > > > policy in a consistent manner. When an AD admin made a change > > > to a > > > LogonRight policy setting, he would have to keep in mind that > > > Linux > > > machines may use the policy settings in ways that were not > > > intended > > > by > > > the > > > AD admin. For example, it would be problematic if a local admin > > > decided > > > to > > > map "login" to NetworkLogonRight, or if some local admins > > > mapped > > > "ftp" > > > to > > > some LogonRight (but other local admins stayed with the > > > default). > > > This > > > would result in inconsistent behavior between different Linux > > > machines, > > > and between Linux machines and Windows machines. Indeed, in the > > > Windows > > > world, the "local" per-machine GPO is given least priority in > > > case > > > of > > > conflict (i.e. ou overrides domain, which overrides site, which > > > overrides > > > local). A solution to this problem of consistency would be to > > > have > > > a > > > centralized GPO that maps pam services to LogonRights, but I > > > don't > > > think > > > we need to implement that in the first release. > > > > > > I think limiting ourselves to InteractiveLogonRight and > > > RemoteInteractiveLogonRight would be less confusing and more > > > predictable > > > for AD admins (resulting in a greater likelihood of them > > > deploying > > > gpo-based access control). They would know that these two > > > LogonRights > > > would be enforced with the same semantics on Windows and Linux > > > machines. > > > They would also know that other LogonRights would not be > > > enforced > > > on > > > Linux > > > machines. Clean and crisp. > > > > > > What do you think? > > > > You make a good argument, but I am not entirely convinced you can > > avoid > > a local mapping unless you provide a GPO mapping, because the > > admin > > must > > be able to adjust mappings for new services installed on the box > > that > > were not included in the upstream provided lists. > > > > So if you already need to provide a way to augment mappings, you > > may > > as > > well handle all rights with reasonable defaults, and let the > > admin > > decide whether they need to change stuff around. > > > > Simo. > > > > Allowing local admins to change stuff from underneath the AD > admin's > directives seems to violate the GPO philosophy of centralized, > consistent application of policy. I don't think AD admins will find > the gpo-based access control feature compelling, if it does not fit > with their mental model of how GPO is supposed to work.
Sorry but I do not buy this argument. The whole GPO policy can be turned on or off in sssd, so if admins do not control the boxes' sssd.conf file they already know their policies are, at best, advisory.
> As you know, LogonRights are existing Windows policy settings (not > Linux-specific settings), so we really do have to honor the intent > of > the settings and the GPO framework.
Indeed, and in order to do that you need to be able to appropriately map arbitrary services.
> Having said that, I don't think we necessarily need to have a > comprehensive implementation in the first release, especially if we > think the GPO mapping is the correct solution (and if we think that > we > may implement that in a subsequent release).
We do not need the support as a GPO deliverable policy, but you need a local mapping for the feature to be usable/testable IMO.
> I think the centralized mapping offered by a future GPO mapping > would > certainly allay the concerns of AD admins, as the power would > remain > in their hands and it would be applied consistently. Implementing > local mapping now, and then adding a centralized mapping later > would > delay deployment and would add too much complexity IMO.
Why ? This is exactly the same as overlaying global policy on top of local policy, I honestly do not see it as any more complex than needed.
> As for how to deal with new services (in the initial > implementation), > two ideas come to mind: > 1) My preference would be that only services included in the > upstream > provided lists will be affected by gpo-based access control. Not > very > extensible, but that's OK if we intend on adding a GPO mapping in a > future release.
Upstream runs on multiple OSs and Linux distributions, within those there is already, I bet, enough conflict to make a single upstream list unfeasible, as pam service names are somewhat arbitrary and customized in different way especially for very distro-specific services like login and graphical session managers.
> 2) Alternatively, we could go with a completely different proposal > that would affect all pam services. Specifically, since remote > login > seems to be an uncommon pam service (we could only come up with > "ssh"), we could declare that "ssh" maps to > RemoteInteractiveLogonRight, and that *all* other services > (including > new services, custom services, etc), map to InteractiveLogonRight.
That would be wrong. I suspect one of the services you really want to control, as a windows admin, is samba file services, and those must be mapped to NetworkLogonRight. And NEtworkLogonRight seem to be generally the most sensible default once you exclude the services you know are interactive login shells.
> While certainly not ideal (and not my preference), I think AD > admins > would find this easier to grok than local mappings, as it would be > predictable and would allow policy authority to remain centralized, > without central directives being manipulated by local admins.
If the admin doesn't grok what services run on a Linux box, they are already doomed I would think. You need at least a passing understanding of the policies you are going to set. We can *definitely* provide a good default set, admins should not be required to provide explicit mappings if the default works for them, but an unchangeable list will severely reduce the utility of the feature.
OK. I forgot that local admins can disable gpo processing, so although AD admins may want centralized control over all domain computers (whether Windows or Linux), they may not be able to get it with this feature. Whether this will be a show-stopper for them remains to be seen. With that in mind, I agree that it makes sense to allow pam services to be mapped to logon rights.
With regard to the default set of mappings, I propose the following (based on previous emails). login/*dm/su* maps to InteractiveLogonRight ssh maps to RemoteInteractiveLogonRight explicit mappings are honored if the service is still unmapped, map it to NetworkLogonRight
I think we can take a page from FreeIPA's configuration, this is the original list of services we provide by default for HBAC:
sshd ftp su login su-l sudo sudo-i gdm gdm-password kdm
To which later updates added: crond vsftpd proftpd pure-ftpd gssftp
Keep in mind that FreeIPA uses also service groups so all the ftp services are grouped under a ftp group.
I think that we can add crond and samba to the first list and use that as the default list.
A few questions for you:
- Does this list make sense?
Mostly, yes.
- Should there be anything special about the default set, or can an
admin re-map services from the default set (i.e. map "ssh" to NetworkLogonRight)?
I would use the following mappings.
InteractiveLogonRight: su, login, su-l, sudo, sudo-i, gdm, gdm-password, kdm RemoteInteractiveLogonRight: sshd NetworkLogonRight: ftp samba BatchLogonRight (?): crond
I am not sure what to use as default fallback for any service that do not match these.
There is a default "remote" service in Fedora, and there is a "other" service which matches any unrecognized service IIRC.
Maybe we could map unknown stuff to ServiceLogonRight which poorly translates to anything useful on Linux I think.
- Should an admin be able to map a service to NULL (indicating that
they don't want this service to be enforced by GPO policy)
So your suggestion would be the unrecognized services would simply be ignored when it comes to GPO enforcing ?
Yes. By essentially providing an opt-in model for pam services (with respect to gpo enforcement), we would be requiring someone to make an informed decision about the service-to-Right mapping (rather than for us to make an arbitrary decision). When an unmapped service is encountered, we would emit a log message (so that the admin can add an explicit mapping, if he forgot to add one). I suspect the distros would be savvy enough to pre-populate the sssd.conf file with distro-specific service mappings, but an individual admin using their own custom pam service might need a nudge.
For example, if an admin forgets to explicitly map a custom service (or doesn't even know he needs to), it would be better for him to receive an "unrecognized service" message in the logs (which would hopefully remind him to add an explicit mapping, after giving it some thought), than for us to arbitrarily map the custom service to some default (which might even result in unintended access denials).
This would be in line with the opt-in model we are using for overall gpo-enforcement (b/c the default is "permissive"). An admin would have to intentionally set the mode to "enforcing", and would have to intentionally provide explicit mappings for non-default services (or even to change a default service mapping).
What do you think?
Explaining on the logs why access to a service was granted or denied is always a good idea. I guess those messages will fell in the audit-messages category but currently SSSD does not treat audit messages specially. Maybe we should start simple and just add an alias to the DEBUG macro called AUDIT? Later on we can start handling them differently than other debug messages but we will already have (at least for newer code) a label in the code where audit information originates.
Can't we just use the sss_log_ext() function that I introduced recently (in util.h). It is currently used only in ad_gpo.c (to deal with gpo permissive mode). Note that this function emits a syslog message to the security log (with or without journald). It does not emit a message to the debug log (although the code separately emits a debug log message).
from ad_gpo.c: sss_log_ext(SSS_LOG_WARNING, LOG_AUTHPRIV, "Warning: user would " \ "have been denied GPO-based logon access if the " \ "ad_gpo_access_control option were set to enforcing " \ "mode.");
(Sorry for hijacking this tread, I'll return now to the gpo and services discussion :-)
I'd like to try to summarize the discussion with a hypothetical man page section of new config options:
ad_gpo_map_interactive (string) A comma-separated list of PAM service names for which access control is evaluated with the help of the AD Interactive Logon Right.
Default: su, login, su-l, sudo, sudo-i, gdm, gdm-password, kdmad_gpo_map_remote_interactive (string) A comma-separated list of PAM service names for which access control is evaluated with the help of the AD Remote Interactive Logon Right.
Default: sshdad_gpo_map_network (string) A comma-separated list of PAM service names for which access control is evaluated with the help of the AD Network Logon Right.
Default: ftpad_gpo_map_batch (string) A comma-separated list of PAM service names for which access control is evaluated with the help of the AD Batch Logon Right.
Default: crondad_gpo_map_service (string) A comma-separated list of PAM service names for which access control is evaluated with the help of the AD Service Logon Right.
Default: Not setad_gpo_default_rights (string) This option defines how access control is evaluated for PAM services which are not explicitly listed in one of the ad_gpo_map_* options. Allowed values are 'interactive', 'remote_interactive', 'network', 'batch' and 'service' to do the evaluation based on the corresponding AD Logon Right. Additionally 'permit' and 'deny' can be used to either always grant or reject access for those PAM services.
Default: denybye, Sumit
Thanks!! This is a great start! Very helpful.
A few comments:
- We should tweak the wording a bit (and also mention the corresponding
Deny Rights). For example, "A comma-separated list of PAM service names for which access control is evaluated based on the AD BatchLogonRight and DenyBatchLogonRight policy settings."
Perhaps..
- We should make the option names describe the contents of the option. For
example, "ad_gpo_service_names_interactive"
I actually liked the "_map_" better. The semantics is what UNIX services you map onto interactive or remote GPO service groups.
The default for ad_gpo_map_network should also include "samba" (in addition to "ftp")
Should we add the various gdm-* service names as interactive: gdm-autologin, gdm-fingerprint, gdm-launch-environment, gdm-pin, gdm-smartcard
Should we add the screen savers as interactive: gnome-screensaver, kscreensaver
I think we should check with Ray Strode (halfline on IRC) about the and screensaver semantics. For instance in https://bugzilla.redhat.com/show_bug.cgi?id=1104756#c16 Ray argued that screensaver only 're-authenticates'.
I tend to agree about the gdm-* services, but again, checking with Ray might be a good idea. I think at least in the past, gdm would do some funky stuff with non-password authentication, like sending the authtoks to several different pam services and checking which ones would let the user through..I'm not sure if it's still the case now after the Gnome 3.x rewrite.
What does gdm-launch-environment do?
- I don't like overloading the ad_gpo_default_rights option so as to
include either a Right or a permit/deny. In fact, I don't think a default Right is needed at all (but the permit/deny might be useful). Assuming there are only a handful of unrecognized rights, there is already a convenient mechanism to specify explicit mappings. We can use a non-overloaded option that can be used to specify permit/deny semantics for unmapped service names. I think this would be more understandable. For example: "ad_gpo_service_names_unmapped_action (string): This option defines how access control is evaluated for PAM services which are not explicitly listed in one of the ad_gpo_service_names_* options. Values of 'permit' and 'deny' can be used to either always grant or always reject access for those PAM services."
Could we do with only providing mapping of PAM services to Logon Rights and denying the rest?
- I think the default for the default/unmapped option should be "permit" rather than "deny" (to be consistent with the opt-in model for overall gpo processing)
I don't like if the fallback or default includes a 'permit' right, then the semantics smell too much like deny lists which are almost always a bad idea.
What exactly do you mean by opt-in model? The 'permissive' option by default?
----- Original Message -----
On Thu, Jul 03, 2014 at 01:39:38AM -0400, Yassir Elley wrote:
----- Original Message -----
On Wed, Jul 02, 2014 at 01:45:00AM -0400, Yassir Elley wrote:
----- Original Message -----
On Tue, 2014-07-01 at 01:50 -0400, Yassir Elley wrote:
----- Original Message ----- > On Sat, 2014-06-28 at 18:01 -0400, Yassir Elley wrote: > > > > ----- Original Message ----- > > > On Sat, 2014-06-28 at 01:20 -0400, Yassir Elley wrote: > > > > > > > > ----- Original Message ----- > > > > > On Thu, 2014-06-26 at 04:54 -0400, Yassir Elley wrote: > > > > > > Hi Simo, > > > > > > > > > > > > I'd like to wrap up this discussion. I propose that we > > > > > > support > > > > > > only > > > > > > the InteractiveLogonRight (for the pam services you > > > > > > mentioned: > > > > > > "login", "*dm, "su*"), and on the > > > > > > RemoteInteractiveLogonRight > > > > > > (for > > > > > > the > > > > > > "ssh" pam service). We should not support the > > > > > > NetworkLogonRight > > > > > > since > > > > > > it is difficult to implement. Do you agree with this > > > > > > proposal? > > > > > > > > > > Well I guess the answer depends on what do you plan to do > > > > > for > > > > > pam > > > > > services that are not listed ? > > > > > Do you always deny access ? Always permit ? > > > > > > > > Since we would only support the InteractiveLogonRight and > > > > RemoteInteractiveLogonRight, we would always permit access > > > > for > > > > other > > > > pam > > > > services (because they would not be governed by gpo-based > > > > access > > > > control, > > > > and this would be clearly documented). > > > > > > > > > > > > > > I think a more reasonable workaround is to define a > > > > > default > > > > > type, > > > > > and > > > > > a > > > > > list of mappings. > > > > > > > > > > If a PAM service is explicitly mapped you use that Right > > > > > to > > > > > decide, > > > > > otherwise the decision falls back to the "default" Right. > > > > > Actually the default right could well be actually > > > > > NetworkLogonRight > > > > > or > > > > > InteractiveLogonRight or something else. As long as you > > > > > can > > > > > change > > > > > the > > > > > mappings locally through some configuration that would > > > > > allow > > > > > the > > > > > admin > > > > > to add mappings according to their needs. Of course > > > > > strong > > > > > guidance > > > > > on which mappings should be used for specific type of > > > > > services > > > > > should > > > > > be > > > > > provided. > > > > > > > > > > Simo. > > > > > > > > > > > > > I would prefer an approach which is more predictable for > > > > the AD > > > > admin. > > > > If > > > > we limit ourselves to InteractiveLogonRight and > > > > RemoteInteractiveLogonRight, the semantics are very clear > > > > (console > > > > login > > > > and remote login), allowing the AD Admin to be confident > > > > that > > > > any > > > > existing > > > > or future policy files containing those rights would be > > > > applied > > > > correctly > > > > and consistently, regardless of whether the machine is > > > > running > > > > Linux or > > > > Windows. > > > > > > > > Also, I suspect AD admins would not like per-machine > > > > service > > > > mappings > > > > to be > > > > enforced, since that would defeat the purpose of enforcing > > > > a > > > > centralized > > > > policy in a consistent manner. When an AD admin made a > > > > change > > > > to a > > > > LogonRight policy setting, he would have to keep in mind > > > > that > > > > Linux > > > > machines may use the policy settings in ways that were not > > > > intended > > > > by > > > > the > > > > AD admin. For example, it would be problematic if a local > > > > admin > > > > decided > > > > to > > > > map "login" to NetworkLogonRight, or if some local admins > > > > mapped > > > > "ftp" > > > > to > > > > some LogonRight (but other local admins stayed with the > > > > default). > > > > This > > > > would result in inconsistent behavior between different > > > > Linux > > > > machines, > > > > and between Linux machines and Windows machines. Indeed, in > > > > the > > > > Windows > > > > world, the "local" per-machine GPO is given least priority > > > > in > > > > case > > > > of > > > > conflict (i.e. ou overrides domain, which overrides site, > > > > which > > > > overrides > > > > local). A solution to this problem of consistency would be > > > > to > > > > have > > > > a > > > > centralized GPO that maps pam services to LogonRights, but > > > > I > > > > don't > > > > think > > > > we need to implement that in the first release. > > > > > > > > I think limiting ourselves to InteractiveLogonRight and > > > > RemoteInteractiveLogonRight would be less confusing and > > > > more > > > > predictable > > > > for AD admins (resulting in a greater likelihood of them > > > > deploying > > > > gpo-based access control). They would know that these two > > > > LogonRights > > > > would be enforced with the same semantics on Windows and > > > > Linux > > > > machines. > > > > They would also know that other LogonRights would not be > > > > enforced > > > > on > > > > Linux > > > > machines. Clean and crisp. > > > > > > > > What do you think? > > > > > > You make a good argument, but I am not entirely convinced you > > > can > > > avoid > > > a local mapping unless you provide a GPO mapping, because the > > > admin > > > must > > > be able to adjust mappings for new services installed on the > > > box > > > that > > > were not included in the upstream provided lists. > > > > > > So if you already need to provide a way to augment mappings, > > > you > > > may > > > as > > > well handle all rights with reasonable defaults, and let the > > > admin > > > decide whether they need to change stuff around. > > > > > > Simo. > > > > > > > Allowing local admins to change stuff from underneath the AD > > admin's > > directives seems to violate the GPO philosophy of centralized, > > consistent application of policy. I don't think AD admins will > > find > > the gpo-based access control feature compelling, if it does not > > fit > > with their mental model of how GPO is supposed to work. > > Sorry but I do not buy this argument. The whole GPO policy can be > turned > on or off in sssd, so if admins do not control the boxes' > sssd.conf > file > they already know their policies are, at best, advisory. > > > As you know, LogonRights are existing Windows policy settings > > (not > > Linux-specific settings), so we really do have to honor the > > intent > > of > > the settings and the GPO framework. > > Indeed, and in order to do that you need to be able to > appropriately > map > arbitrary services. > > > Having said that, I don't think we necessarily need to have a > > comprehensive implementation in the first release, especially > > if we > > think the GPO mapping is the correct solution (and if we think > > that > > we > > may implement that in a subsequent release). > > We do not need the support as a GPO deliverable policy, but you > need > a > local mapping for the feature to be usable/testable IMO. > > > I think the centralized mapping offered by a future GPO mapping > > would > > certainly allay the concerns of AD admins, as the power would > > remain > > in their hands and it would be applied consistently. > > Implementing > > local mapping now, and then adding a centralized mapping later > > would > > delay deployment and would add too much complexity IMO. > > Why ? This is exactly the same as overlaying global policy on top > of > local policy, I honestly do not see it as any more complex than > needed. > > > As for how to deal with new services (in the initial > > implementation), > > two ideas come to mind: > > 1) My preference would be that only services included in the > > upstream > > provided lists will be affected by gpo-based access control. > > Not > > very > > extensible, but that's OK if we intend on adding a GPO mapping > > in a > > future release. > > Upstream runs on multiple OSs and Linux distributions, within > those > there is already, I bet, enough conflict to make a single > upstream > list > unfeasible, as pam service names are somewhat arbitrary and > customized > in different way especially for very distro-specific services > like > login > and graphical session managers. > > > 2) Alternatively, we could go with a completely different > > proposal > > that would affect all pam services. Specifically, since remote > > login > > seems to be an uncommon pam service (we could only come up with > > "ssh"), we could declare that "ssh" maps to > > RemoteInteractiveLogonRight, and that *all* other services > > (including > > new services, custom services, etc), map to > > InteractiveLogonRight. > > That would be wrong. I suspect one of the services you really > want to > control, as a windows admin, is samba file services, and those > must > be > mapped to NetworkLogonRight. > And NEtworkLogonRight seem to be generally the most sensible > default > once you exclude the services you know are interactive login > shells. > > > While certainly not ideal (and not my preference), I think AD > > admins > > would find this easier to grok than local mappings, as it would > > be > > predictable and would allow policy authority to remain > > centralized, > > without central directives being manipulated by local admins. > > If the admin doesn't grok what services run on a Linux box, they > are > already doomed I would think. You need at least a passing > understanding > of the policies you are going to set. We can *definitely* provide > a > good > default set, admins should not be required to provide explicit > mappings > if the default works for them, but an unchangeable list will > severely > reduce the utility of the feature. >
OK. I forgot that local admins can disable gpo processing, so although AD admins may want centralized control over all domain computers (whether Windows or Linux), they may not be able to get it with this feature. Whether this will be a show-stopper for them remains to be seen. With that in mind, I agree that it makes sense to allow pam services to be mapped to logon rights.
With regard to the default set of mappings, I propose the following (based on previous emails). login/*dm/su* maps to InteractiveLogonRight ssh maps to RemoteInteractiveLogonRight explicit mappings are honored if the service is still unmapped, map it to NetworkLogonRight
I think we can take a page from FreeIPA's configuration, this is the original list of services we provide by default for HBAC:
sshd ftp su login su-l sudo sudo-i gdm gdm-password kdm
To which later updates added: crond vsftpd proftpd pure-ftpd gssftp
Keep in mind that FreeIPA uses also service groups so all the ftp services are grouped under a ftp group.
I think that we can add crond and samba to the first list and use that as the default list.
A few questions for you:
- Does this list make sense?
Mostly, yes.
- Should there be anything special about the default set, or can an
admin re-map services from the default set (i.e. map "ssh" to NetworkLogonRight)?
I would use the following mappings.
InteractiveLogonRight: su, login, su-l, sudo, sudo-i, gdm, gdm-password, kdm RemoteInteractiveLogonRight: sshd NetworkLogonRight: ftp samba BatchLogonRight (?): crond
I am not sure what to use as default fallback for any service that do not match these.
There is a default "remote" service in Fedora, and there is a "other" service which matches any unrecognized service IIRC.
Maybe we could map unknown stuff to ServiceLogonRight which poorly translates to anything useful on Linux I think.
- Should an admin be able to map a service to NULL (indicating that
they don't want this service to be enforced by GPO policy)
So your suggestion would be the unrecognized services would simply be ignored when it comes to GPO enforcing ?
Yes. By essentially providing an opt-in model for pam services (with respect to gpo enforcement), we would be requiring someone to make an informed decision about the service-to-Right mapping (rather than for us to make an arbitrary decision). When an unmapped service is encountered, we would emit a log message (so that the admin can add an explicit mapping, if he forgot to add one). I suspect the distros would be savvy enough to pre-populate the sssd.conf file with distro-specific service mappings, but an individual admin using their own custom pam service might need a nudge.
For example, if an admin forgets to explicitly map a custom service (or doesn't even know he needs to), it would be better for him to receive an "unrecognized service" message in the logs (which would hopefully remind him to add an explicit mapping, after giving it some thought), than for us to arbitrarily map the custom service to some default (which might even result in unintended access denials).
This would be in line with the opt-in model we are using for overall gpo-enforcement (b/c the default is "permissive"). An admin would have to intentionally set the mode to "enforcing", and would have to intentionally provide explicit mappings for non-default services (or even to change a default service mapping).
What do you think?
Explaining on the logs why access to a service was granted or denied is always a good idea. I guess those messages will fell in the audit-messages category but currently SSSD does not treat audit messages specially. Maybe we should start simple and just add an alias to the DEBUG macro called AUDIT? Later on we can start handling them differently than other debug messages but we will already have (at least for newer code) a label in the code where audit information originates.
Can't we just use the sss_log_ext() function that I introduced recently (in util.h). It is currently used only in ad_gpo.c (to deal with gpo permissive mode). Note that this function emits a syslog message to the security log (with or without journald). It does not emit a message to the debug log (although the code separately emits a debug log message).
from ad_gpo.c: sss_log_ext(SSS_LOG_WARNING, LOG_AUTHPRIV, "Warning: user would " \ "have been denied GPO-based logon access if the " \ "ad_gpo_access_control option were set to enforcing " \ "mode.");
(Sorry for hijacking this tread, I'll return now to the gpo and services discussion :-)
I'd like to try to summarize the discussion with a hypothetical man page section of new config options:
ad_gpo_map_interactive (string) A comma-separated list of PAM service names for which access control is evaluated with the help of the AD Interactive Logon Right.
Default: su, login, su-l, sudo, sudo-i, gdm, gdm-password, kdmad_gpo_map_remote_interactive (string) A comma-separated list of PAM service names for which access control is evaluated with the help of the AD Remote Interactive Logon Right.
Default: sshdad_gpo_map_network (string) A comma-separated list of PAM service names for which access control is evaluated with the help of the AD Network Logon Right.
Default: ftpad_gpo_map_batch (string) A comma-separated list of PAM service names for which access control is evaluated with the help of the AD Batch Logon Right.
Default: crondad_gpo_map_service (string) A comma-separated list of PAM service names for which access control is evaluated with the help of the AD Service Logon Right.
Default: Not setad_gpo_default_rights (string) This option defines how access control is evaluated for PAM services which are not explicitly listed in one of the ad_gpo_map_* options. Allowed values are 'interactive', 'remote_interactive', 'network', 'batch' and 'service' to do the evaluation based on the corresponding AD Logon Right. Additionally 'permit' and 'deny' can be used to either always grant or reject access for those PAM services.
Default: denybye, Sumit
Thanks!! This is a great start! Very helpful.
A few comments:
- We should tweak the wording a bit (and also mention the corresponding
Deny Rights). For example, "A comma-separated list of PAM service names for which access control is evaluated based on the AD BatchLogonRight and DenyBatchLogonRight policy settings."
Perhaps..
- We should make the option names describe the contents of the option. For
example, "ad_gpo_service_names_interactive"
I actually liked the "_map_" better. The semantics is what UNIX services you map onto interactive or remote GPO service groups.
My thinking was that the sssd config option names typically describe the expected option value(s). For example, ad_domain expects a domain; ad_hostname expects a hostname. In this case, since the values are going to be service names, I thought it would be appropriate to include "service_names" in the option.
Also, in the case of "ad_gpo_map_interactive", if I looked only at that option name, I would think the expected value was some sort of a map of tuples, such as (login=>interactive),(su=>interactive), etc.
The most accurate name would be "ad_gpo_pam_service_names_that_map_to_interactive_logon_right", but that is too long, of course. :)
Having said all that, if the team has a strong preference for "ad_gpo_map_interactive", etc, then we can go with that.
- The default for ad_gpo_map_network should also include "samba" (in
addition to "ftp")
- Should we add the various gdm-* service names as interactive:
gdm-autologin, gdm-fingerprint, gdm-launch-environment, gdm-pin, gdm-smartcard
- Should we add the screen savers as interactive: gnome-screensaver,
kscreensaver
I think we should check with Ray Strode (halfline on IRC) about the and screensaver semantics. For instance in https://bugzilla.redhat.com/show_bug.cgi?id=1104756#c16 Ray argued that screensaver only 're-authenticates'.
I tend to agree about the gdm-* services, but again, checking with Ray might be a good idea. I think at least in the past, gdm would do some funky stuff with non-password authentication, like sending the authtoks to several different pam services and checking which ones would let the user through..I'm not sure if it's still the case now after the Gnome 3.x rewrite.
What does gdm-launch-environment do?
OK. I will check with Ray. I don't know what gdm-launch-environment does. I just noticed it was in my /etc/pam.d
- I don't like overloading the ad_gpo_default_rights option so as to
include either a Right or a permit/deny. In fact, I don't think a default Right is needed at all (but the permit/deny might be useful). Assuming there are only a handful of unrecognized rights, there is already a convenient mechanism to specify explicit mappings. We can use a non-overloaded option that can be used to specify permit/deny semantics for unmapped service names. I think this would be more understandable. For example: "ad_gpo_service_names_unmapped_action (string): This option defines how access control is evaluated for PAM services which are not explicitly listed in one of the ad_gpo_service_names_* options. Values of 'permit' and 'deny' can be used to either always grant or always reject access for those PAM services."
Could we do with only providing mapping of PAM services to Logon Rights and denying the rest?
- I think the default for the default/unmapped option should be "permit"
rather than "deny" (to be consistent with the opt-in model for overall gpo processing)
I don't like if the fallback or default includes a 'permit' right, then the semantics smell too much like deny lists which are almost always a bad idea.
What exactly do you mean by opt-in model? The 'permissive' option by default?
Yes. Since we require the admin to opt-in to overall gpo enforcement (by changing 'permissive' to 'enforcing'), I thought it would be consistent to also require the admin to opt-in to service-name mappings. However, since the admin already has to manually make the change to 'enforcing', then they presumably know what they're doing, and will be able to debug any issues they get in which unmapped service names are being denied access.
In short, I agree that we should deny by default.
Do you think we should allow unmapped service names to be mapped to a default right (like "interactive")? Or should we only allow unmapped service names to correspond to "permit" or "deny"? Or should we allow both?
Regards, Yassir.
----- Original Message -----
On Thu, Jul 03, 2014 at 01:39:38AM -0400, Yassir Elley wrote:
----- Original Message ----- 4. Should we add the various gdm-* service names as interactive: gdm-autologin, gdm-fingerprint, gdm-launch-environment, gdm-pin, gdm-smartcard
- Should we add the screen savers as interactive: gnome-screensaver,
kscreensaver
I think we should check with Ray Strode (halfline on IRC) about the and screensaver semantics. For instance in https://bugzilla.redhat.com/show_bug.cgi?id=1104756#c16 Ray argued that screensaver only 're-authenticates'.
I tend to agree about the gdm-* services, but again, checking with Ray might be a good idea. I think at least in the past, gdm would do some funky stuff with non-password authentication, like sending the authtoks to several different pam services and checking which ones would let the user through..I'm not sure if it's still the case now after the Gnome 3.x rewrite.
What does gdm-launch-environment do?
I chatted with Ray Strode, who said we should provide defaults (of interactive) for gdm-password, gdm-smartcard, and gdm-fingerprint. The pam gnome-screensaver service has apparently been replaced with a gnome-shell lock screen (starting with RHEL 7). Even on RHEL 6, while the pam_acct_mgmt call is made when unlocking the gnome-screensaver, the results are apparently ignored (b/c the user already has a running session; the lock simply hides the gnome-shell display). He didn't think default values were needed for any of the other gdm related services, such as: * gdm-pin (no longer supported) * gdm-autologin (password-less login) * gdm-launch-environment (used to launch system session for gdm user to run login process) Note that there is no pam service simply named "gdm".
On the other side, there seem to be four pam services related to kdm: kdm, kdm-np, kcheckpass, and kscreensaver. We should definitely include a default for kdm, but we probably don't care about kdm-np (no-password). Does anyone know how kscreensaver differs from kcheckpass (both have identical pam files, which essentially include system-auth for all calls (auth, account, session, password). Perhaps we should add defaults for both kcheckpass and kscreensaver.
Comments?
Regards, Yassir.
On Thu, Jul 31, 2014 at 01:58:06PM -0400, Yassir Elley wrote:
----- Original Message -----
On Thu, Jul 03, 2014 at 01:39:38AM -0400, Yassir Elley wrote:
----- Original Message ----- 4. Should we add the various gdm-* service names as interactive: gdm-autologin, gdm-fingerprint, gdm-launch-environment, gdm-pin, gdm-smartcard
- Should we add the screen savers as interactive: gnome-screensaver,
kscreensaver
I think we should check with Ray Strode (halfline on IRC) about the and screensaver semantics. For instance in https://bugzilla.redhat.com/show_bug.cgi?id=1104756#c16 Ray argued that screensaver only 're-authenticates'.
I tend to agree about the gdm-* services, but again, checking with Ray might be a good idea. I think at least in the past, gdm would do some funky stuff with non-password authentication, like sending the authtoks to several different pam services and checking which ones would let the user through..I'm not sure if it's still the case now after the Gnome 3.x rewrite.
What does gdm-launch-environment do?
I chatted with Ray Strode, who said we should provide defaults (of interactive) for gdm-password, gdm-smartcard, and gdm-fingerprint. The pam gnome-screensaver service has apparently been replaced with a gnome-shell lock screen (starting with RHEL 7). Even on RHEL 6, while the pam_acct_mgmt call is made when unlocking the gnome-screensaver, the results are apparently ignored (b/c the user already has a running session; the lock simply hides the gnome-shell display).
Right, I found this out as well, it was a bit suprising to me, but meh, the user's TGT would expire anyway..
He didn't think default values were needed for any of the other gdm related services, such as:
- gdm-pin (no longer supported)
- gdm-autologin (password-less login)
- gdm-launch-environment (used to launch system session for gdm user to run login process)
Note that there is no pam service simply named "gdm".
On the other side, there seem to be four pam services related to kdm: kdm, kdm-np, kcheckpass, and kscreensaver. We should definitely include a default for kdm, but we probably don't care about kdm-np (no-password). Does anyone know how kscreensaver differs from kcheckpass (both have identical pam files, which essentially include system-auth for all calls (auth, account, session, password). Perhaps we should add defaults for both kcheckpass and kscreensaver.
I'm sorry, I have no idea about KDE at all...I know that ltinkl@r.c does a bit of KDE development, maybe he would get an idea.
Comments?
Regards, Yassir. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
----- Original Message -----
On Thu, Jul 31, 2014 at 01:58:06PM -0400, Yassir Elley wrote:
----- Original Message -----
On Thu, Jul 03, 2014 at 01:39:38AM -0400, Yassir Elley wrote:
----- Original Message ----- 4. Should we add the various gdm-* service names as interactive: gdm-autologin, gdm-fingerprint, gdm-launch-environment, gdm-pin, gdm-smartcard
- Should we add the screen savers as interactive: gnome-screensaver,
kscreensaver
I think we should check with Ray Strode (halfline on IRC) about the and screensaver semantics. For instance in https://bugzilla.redhat.com/show_bug.cgi?id=1104756#c16 Ray argued that screensaver only 're-authenticates'.
I tend to agree about the gdm-* services, but again, checking with Ray might be a good idea. I think at least in the past, gdm would do some funky stuff with non-password authentication, like sending the authtoks to several different pam services and checking which ones would let the user through..I'm not sure if it's still the case now after the Gnome 3.x rewrite.
What does gdm-launch-environment do?
I chatted with Ray Strode, who said we should provide defaults (of interactive) for gdm-password, gdm-smartcard, and gdm-fingerprint. The pam gnome-screensaver service has apparently been replaced with a gnome-shell lock screen (starting with RHEL 7). Even on RHEL 6, while the pam_acct_mgmt call is made when unlocking the gnome-screensaver, the results are apparently ignored (b/c the user already has a running session; the lock simply hides the gnome-shell display).
Right, I found this out as well, it was a bit suprising to me, but meh, the user's TGT would expire anyway..
He didn't think default values were needed for any of the other gdm related services, such as:
- gdm-pin (no longer supported)
- gdm-autologin (password-less login)
- gdm-launch-environment (used to launch system session for gdm user to run
login process) Note that there is no pam service simply named "gdm".
On the other side, there seem to be four pam services related to kdm: kdm, kdm-np, kcheckpass, and kscreensaver. We should definitely include a default for kdm, but we probably don't care about kdm-np (no-password). Does anyone know how kscreensaver differs from kcheckpass (both have identical pam files, which essentially include system-auth for all calls (auth, account, session, password). Perhaps we should add defaults for both kcheckpass and kscreensaver.
I'm sorry, I have no idea about KDE at all...I know that ltinkl@r.c does a bit of KDE development, maybe he would get an idea.
Couldn't get in touch with ltinkl, but halfline pointed me to dvratil, who I chatted with instead. When a user tries to unlock the screen, kscreenlocker_greet calls kcheckpass, which calls pam_authenticate (but not pam_acct_mgmt). Also, kscreensaver is apparently legacy. So, among the KDE pam services, I think we should only provide a default for "kdm".
Here is a summary of the pam service names for which I am planning on providing default logon rights (which can, of course, be overridden by configuration).
Default = InteractiveLogonRight * login, su, su-l, sudo, sudo-i, gdm-password, gdm-fingerprint, gdm-smartcard, kdm
Default = RemoteInteractiveLogonRight * sshd
Default = NetworkLogonRight * ftp, samba
Default = BatchLogonRight * crond
Regards, Yassir.
On Tue, Aug 05, 2014 at 05:14:17PM -0400, Yassir Elley wrote:
----- Original Message -----
On Thu, Jul 31, 2014 at 01:58:06PM -0400, Yassir Elley wrote:
----- Original Message -----
On Thu, Jul 03, 2014 at 01:39:38AM -0400, Yassir Elley wrote:
----- Original Message ----- 4. Should we add the various gdm-* service names as interactive: gdm-autologin, gdm-fingerprint, gdm-launch-environment, gdm-pin, gdm-smartcard
- Should we add the screen savers as interactive: gnome-screensaver,
kscreensaver
I think we should check with Ray Strode (halfline on IRC) about the and screensaver semantics. For instance in https://bugzilla.redhat.com/show_bug.cgi?id=1104756#c16 Ray argued that screensaver only 're-authenticates'.
I tend to agree about the gdm-* services, but again, checking with Ray might be a good idea. I think at least in the past, gdm would do some funky stuff with non-password authentication, like sending the authtoks to several different pam services and checking which ones would let the user through..I'm not sure if it's still the case now after the Gnome 3.x rewrite.
What does gdm-launch-environment do?
I chatted with Ray Strode, who said we should provide defaults (of interactive) for gdm-password, gdm-smartcard, and gdm-fingerprint. The pam gnome-screensaver service has apparently been replaced with a gnome-shell lock screen (starting with RHEL 7). Even on RHEL 6, while the pam_acct_mgmt call is made when unlocking the gnome-screensaver, the results are apparently ignored (b/c the user already has a running session; the lock simply hides the gnome-shell display).
Right, I found this out as well, it was a bit suprising to me, but meh, the user's TGT would expire anyway..
He didn't think default values were needed for any of the other gdm related services, such as:
- gdm-pin (no longer supported)
- gdm-autologin (password-less login)
- gdm-launch-environment (used to launch system session for gdm user to run
login process) Note that there is no pam service simply named "gdm".
On the other side, there seem to be four pam services related to kdm: kdm, kdm-np, kcheckpass, and kscreensaver. We should definitely include a default for kdm, but we probably don't care about kdm-np (no-password). Does anyone know how kscreensaver differs from kcheckpass (both have identical pam files, which essentially include system-auth for all calls (auth, account, session, password). Perhaps we should add defaults for both kcheckpass and kscreensaver.
I'm sorry, I have no idea about KDE at all...I know that ltinkl@r.c does a bit of KDE development, maybe he would get an idea.
Couldn't get in touch with ltinkl, but halfline pointed me to dvratil, who I chatted with instead. When a user tries to unlock the screen, kscreenlocker_greet calls kcheckpass, which calls pam_authenticate (but not pam_acct_mgmt). Also, kscreensaver is apparently legacy. So, among the KDE pam services, I think we should only provide a default for "kdm".
Here is a summary of the pam service names for which I am planning on providing default logon rights (which can, of course, be overridden by configuration).
Default = InteractiveLogonRight
- login, su, su-l, sudo, sudo-i, gdm-password, gdm-fingerprint, gdm-smartcard, kdm
Default = RemoteInteractiveLogonRight
- sshd
Default = NetworkLogonRight
- ftp, samba
Default = BatchLogonRight
- crond
Regards, Yassir.
We had a long and useful conversation about this topic on #sssd with one of our users -- I'm adding him to the CC list so we can continue the conversation.
Thanks Jakub.
Essentially I wanted to address the integration of rights assignments to sudo and potentially other components. Sudo is a two factor item - first the authentication, then the filter of rules based on users or groups that determine whether the calling user actually has rights.
Integrating that into InteractiveLogonRight seems perfectly fine in a desktop environment, but one of the common themes in windows server hardening is locking down the InteractiveLogonRight and removing all but Domain and Local Administrators, or adding a DenyInteractiveLogonRight entry for the user groups, and granting only RemoteInteractiveLogonRight.
Our discussion involved a few theoreticals and some testing.
For example, let's say a user is a member of a group that has RemoteInteractiveLogonRight but Deny Local Logon. In this case, an administrator would expect that the user can log in and utilize sudo to access authorized privileged commands, similar to how in Windows, a user can log in using only this right and access other services, batch jobs, or privileged operations (assuming they're authorized) using RunAs and UAC. In this Scenario, however, sudo would not authenticate the user, since they are in Deny Local Logon.
This is a very common setup for servers - and Deny's always take precedence over their associated Allow in the context of the Local or Remote Interactive.
The discussion concluded with a concern on whether sudo and sudo-i should even be included in the rights policies given its two-factor nature. Would a security concern be raised by allowing sudo to authenticate a user regardless of these memberships? As far as I'm aware, sudo is called from an existing logon, cron, or other session.
Hope that sums everything we talked about up!
-Michichael
On Fri, Aug 8, 2014 at 1:58 PM, Jakub Hrozek jhrozek@redhat.com wrote:
On Tue, Aug 05, 2014 at 05:14:17PM -0400, Yassir Elley wrote:
----- Original Message -----
On Thu, Jul 31, 2014 at 01:58:06PM -0400, Yassir Elley wrote:
----- Original Message -----
On Thu, Jul 03, 2014 at 01:39:38AM -0400, Yassir Elley wrote:
----- Original Message ----- 4. Should we add the various gdm-* service names as interactive: gdm-autologin, gdm-fingerprint, gdm-launch-environment, gdm-pin, gdm-smartcard
- Should we add the screen savers as interactive:
gnome-screensaver,
kscreensaver
I think we should check with Ray Strode (halfline on IRC) about the and screensaver semantics. For instance in https://bugzilla.redhat.com/show_bug.cgi?id=1104756#c16 Ray
argued that
screensaver only 're-authenticates'.
I tend to agree about the gdm-* services, but again, checking with
Ray
might be a good idea. I think at least in the past, gdm would do
some
funky stuff with non-password authentication, like sending the
authtoks
to several different pam services and checking which ones would
let the
user through..I'm not sure if it's still the case now after the
Gnome
3.x rewrite.
What does gdm-launch-environment do?
I chatted with Ray Strode, who said we should provide defaults (of interactive) for gdm-password, gdm-smartcard, and gdm-fingerprint.
The pam
gnome-screensaver service has apparently been replaced with a
gnome-shell
lock screen (starting with RHEL 7). Even on RHEL 6, while the pam_acct_mgmt call is made when unlocking the gnome-screensaver, the results are apparently ignored (b/c the user already has a running session; the lock simply hides the gnome-shell display).
Right, I found this out as well, it was a bit suprising to me, but meh, the user's TGT would expire anyway..
He didn't think default values were needed for any of the other gdm
related
services, such as:
- gdm-pin (no longer supported)
- gdm-autologin (password-less login)
- gdm-launch-environment (used to launch system session for gdm user
to run
login process) Note that there is no pam service simply named "gdm".
On the other side, there seem to be four pam services related to
kdm: kdm,
kdm-np, kcheckpass, and kscreensaver. We should definitely include a default for kdm, but we probably don't care about kdm-np
(no-password).
Does anyone know how kscreensaver differs from kcheckpass (both have identical pam files, which essentially include system-auth for all
calls
(auth, account, session, password). Perhaps we should add defaults
for
both kcheckpass and kscreensaver.
I'm sorry, I have no idea about KDE at all...I know that ltinkl@r.c
does a
bit of KDE development, maybe he would get an idea.
Couldn't get in touch with ltinkl, but halfline pointed me to dvratil,
who I chatted with instead. When a user tries to unlock the screen, kscreenlocker_greet calls kcheckpass, which calls pam_authenticate (but not pam_acct_mgmt). Also, kscreensaver is apparently legacy. So, among the KDE pam services, I think we should only provide a default for "kdm".
Here is a summary of the pam service names for which I am planning on
providing default logon rights (which can, of course, be overridden by configuration).
Default = InteractiveLogonRight
- login, su, su-l, sudo, sudo-i, gdm-password, gdm-fingerprint,
gdm-smartcard, kdm
Default = RemoteInteractiveLogonRight
- sshd
Default = NetworkLogonRight
- ftp, samba
Default = BatchLogonRight
- crond
Regards, Yassir.
We had a long and useful conversation about this topic on #sssd with one of our users -- I'm adding him to the CC list so we can continue the conversation.
----- Original Message -----
Thanks Jakub.
Essentially I wanted to address the integration of rights assignments to sudo and potentially other components. Sudo is a two factor item - first the authentication, then the filter of rules based on users or groups that determine whether the calling user actually has rights.
In our case, when a user calls "sudo ls", I think it is a three-step procedure: 1) sudo calls pam_authenticate to authenticate the user 2) sudo calls pam_acct_mgmt to make sure that the account is not locked, that the ldap/gpo policies permit the user to run sudo, etc 3) sudo refers to /etc/sudoers to determine if it can perform the sudo action (i.e. "ls").
The GPO Logon Rights relate to step (2) of this procedure.
Integrating that into InteractiveLogonRight seems perfectly fine in a desktop environment, but one of the common themes in windows server hardening is locking down the InteractiveLogonRight and removing all but Domain and Local Administrators, or adding a DenyInteractiveLogonRight entry for the user groups, and granting only RemoteInteractiveLogonRight.
Our discussion involved a few theoreticals and some testing.
For example, let's say a user is a member of a group that has RemoteInteractiveLogonRight but Deny Local Logon. In this case, an administrator would expect that the user can log in and utilize sudo to access authorized privileged commands, similar to how in Windows, a user can log in using only this right and access other services, batch jobs, or privileged operations (assuming they're authorized) using RunAs and UAC. In this Scenario, however, sudo would not authenticate the user, since they are in Deny Local Logon.
You assert that Windows would allow a user to perform remote login (and then access other services, batch jobs, privileged operations) using only the RemoteInteractiveLogonRight. Is your assertion based on actual testing on a Windows client? I ask because this is not my understanding. I would expect that the RemoteInteractiveLogonRight would be consulted when the user used RemoteDesktop on a Windows client to login to the remote Windows server, and that the InteractiveLogonRight (Allow/Deny Local Logon) would be consulted when the user attempted to perform a privileged operation (using RunAs or UAC). However, I haven't actually tested this yet, so it would be useful to know if you have already tested this.
This is a very common setup for servers - and Deny's always take precedence over their associated Allow in the context of the Local or Remote Interactive.
Yes. In fact, Deny's take precedence for all LogonRights, including (Local)InteractiveLogonRight, RemoteInteractiveLogonRight, NetworkLogonRight, ServiceLogonRight, and BatchLogonRight.
The discussion concluded with a concern on whether sudo and sudo-i should even be included in the rights policies given its two-factor nature. Would a security concern be raised by allowing sudo to authenticate a user regardless of these memberships? As far as I'm aware, sudo is called from an existing logon, cron, or other session.
Are you suggesting that sudo skip all of the pam_acct_mgmt checks (checking for locked accounts, ldap filter policies), or that it skip only the gpo policy check?
Hope that sums everything we talked about up!
-Michichael
Thanks for your input. It is an interesting discussion!
Regards, Yassir.
On Fri, Aug 8, 2014 at 1:58 PM, Jakub Hrozek < jhrozek@redhat.com > wrote:
On Tue, Aug 05, 2014 at 05:14:17PM -0400, Yassir Elley wrote:
----- Original Message -----
On Thu, Jul 31, 2014 at 01:58:06PM -0400, Yassir Elley wrote:
----- Original Message -----
On Thu, Jul 03, 2014 at 01:39:38AM -0400, Yassir Elley wrote:
----- Original Message ----- 4. Should we add the various gdm-* service names as interactive: gdm-autologin, gdm-fingerprint, gdm-launch-environment, gdm-pin, gdm-smartcard
- Should we add the screen savers as interactive:
gnome-screensaver, kscreensaver
I think we should check with Ray Strode (halfline on IRC) about the and screensaver semantics. For instance in https://bugzilla.redhat.com/show_bug.cgi?id=1104756#c16 Ray argued that screensaver only 're-authenticates'.
I tend to agree about the gdm-* services, but again, checking with Ray might be a good idea. I think at least in the past, gdm would do some funky stuff with non-password authentication, like sending the authtoks to several different pam services and checking which ones would let the user through..I'm not sure if it's still the case now after the Gnome 3.x rewrite.
What does gdm-launch-environment do?
I chatted with Ray Strode, who said we should provide defaults (of interactive) for gdm-password, gdm-smartcard, and gdm-fingerprint. The pam gnome-screensaver service has apparently been replaced with a gnome-shell lock screen (starting with RHEL 7). Even on RHEL 6, while the pam_acct_mgmt call is made when unlocking the gnome-screensaver, the results are apparently ignored (b/c the user already has a running session; the lock simply hides the gnome-shell display).
Right, I found this out as well, it was a bit suprising to me, but meh, the user's TGT would expire anyway..
He didn't think default values were needed for any of the other gdm related services, such as:
- gdm-pin (no longer supported)
- gdm-autologin (password-less login)
- gdm-launch-environment (used to launch system session for gdm user to
run login process) Note that there is no pam service simply named "gdm".
On the other side, there seem to be four pam services related to kdm: kdm, kdm-np, kcheckpass, and kscreensaver. We should definitely include a default for kdm, but we probably don't care about kdm-np (no-password). Does anyone know how kscreensaver differs from kcheckpass (both have identical pam files, which essentially include system-auth for all calls (auth, account, session, password). Perhaps we should add defaults for both kcheckpass and kscreensaver.
I'm sorry, I have no idea about KDE at all...I know that ltinkl@r.c does a bit of KDE development, maybe he would get an idea.
Couldn't get in touch with ltinkl, but halfline pointed me to dvratil, who I chatted with instead. When a user tries to unlock the screen, kscreenlocker_greet calls kcheckpass, which calls pam_authenticate (but not pam_acct_mgmt). Also, kscreensaver is apparently legacy. So, among the KDE pam services, I think we should only provide a default for "kdm".
Here is a summary of the pam service names for which I am planning on providing default logon rights (which can, of course, be overridden by configuration).
Default = InteractiveLogonRight
- login, su, su-l, sudo, sudo-i, gdm-password, gdm-fingerprint,
gdm-smartcard, kdm
Default = RemoteInteractiveLogonRight
- sshd
Default = NetworkLogonRight
- ftp, samba
Default = BatchLogonRight
- crond
Regards, Yassir.
We had a long and useful conversation about this topic on #sssd with one of our users -- I'm adding him to the CC list so we can continue the conversation.
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On Mon, 2014-08-11 at 11:59 -0400, Yassir Elley wrote:
In our case, when a user calls "sudo ls", I think it is a three-step procedure:
- sudo calls pam_authenticate to authenticate the user
- sudo calls pam_acct_mgmt to make sure that the account is not
locked, that the ldap/gpo policies permit the user to run sudo, etc 3) sudo refers to /etc/sudoers to determine if it can perform the sudo action (i.e. "ls").
The GPO Logon Rights relate to step (2) of this procedure.
Except we do not have a logon right in windows that really matches what sudo is/does ... besiodes given sudo does its own authorization checks, what's the point of 2 ?
[..]
Are you suggesting that sudo skip all of the pam_acct_mgmt checks (checking for locked accounts, ldap filter policies), or that it skip only the gpo policy check?
Yes I think that is what Michichael and I ended up agreeing is the most sensible solution, given any other would prevent the rightful use of sudo in some situations where it should be allowed.
Simo.
In our case, when a user calls "sudo ls", I think it is a three-step procedure:
- sudo calls pam_authenticate to authenticate the user
- sudo calls pam_acct_mgmt to make sure that the account is not
locked, that the ldap/gpo policies permit the user to run sudo, etc 3) sudo refers to /etc/sudoers to determine if it can perform the sudo action (i.e. "ls").
The GPO Logon Rights relate to step (2) of this procedure.
Forgive me if I'm misunderstanding, but wouldn't the pam_authenticate attempt an authentication against AD if AD was available, and at that phase determine whether it's locked out or not? In testing, a locked account cannot use sudoers, even if it has a session. If AD isn't available, it'd use the cached password (if enabled), but it wouldn't detect a lockout regardless. Step 2 seems moot outside of that permission check.
You assert that Windows would allow a user to perform remote login (and then access other services, batch jobs, privileged operations) using only the RemoteInteractiveLogonRight. Is your assertion based on actual testing on a Windows client? I ask because this is not my understanding. I would expect that the RemoteInteractiveLogonRight would be consulted when the user used RemoteDesktop on a Windows client to login to the remote Windows server, and that the InteractiveLogonRight (Allow/Deny Local Logon) would be consulted when the user attempted to perform a privileged operation (using RunAs or UAC). However, I haven't actually tested this yet, so it would be useful to know if you have already tested this.
Correct, though Windows makes this is a bit muddy. If a user has rights granted for RemoteInteractive, but rights explicitly denied for Local Interactive (I'm going to refer to it as this just to keep the references clear, I think we all understand that it's InteractiveLogonRight), they can remote desktop into a server and perform all manner of activities and privileged operations. However, with deny Local Interactive in place, if their account is used as the target of a RunAs, the SecondaryLogon service ONLY checks Local Interactive, and they would be denied. They can still make changes to registry, run programs or installers under their privileges, etc; but they can't drop into the "console" session or start a Local Interactive session. UAC runs perfectly fine for the user to elevate their rights (if authorized) using these rights; that's what my personal testing has found. I had to use the explicit denies because of how Windows nests its privileges, the explicit deny supersedes an approval, but only for its respective permission (Local Interactive/Deny Local Interactive).
Are you suggesting that sudo skip all of the pam_acct_mgmt checks (checking for locked accounts, ldap filter policies), or that it skip only the gpo policy check?
Our discussion concluded with the recommendation that it skips the gpo policy check, the authentication handles the lockout check if AD is available.
On Mon, Aug 11, 2014 at 9:10 AM, Simo Sorce simo@redhat.com wrote:
On Mon, 2014-08-11 at 11:59 -0400, Yassir Elley wrote:
In our case, when a user calls "sudo ls", I think it is a three-step procedure:
- sudo calls pam_authenticate to authenticate the user
- sudo calls pam_acct_mgmt to make sure that the account is not
locked, that the ldap/gpo policies permit the user to run sudo, etc 3) sudo refers to /etc/sudoers to determine if it can perform the sudo action (i.e. "ls").
The GPO Logon Rights relate to step (2) of this procedure.
Except we do not have a logon right in windows that really matches what sudo is/does ... besiodes given sudo does its own authorization checks, what's the point of 2 ?
[..]
Are you suggesting that sudo skip all of the pam_acct_mgmt checks (checking for locked accounts, ldap filter policies), or that it skip only the gpo policy check?
Yes I think that is what Michichael and I ended up agreeing is the most sensible solution, given any other would prevent the rightful use of sudo in some situations where it should be allowed.
Simo.
-- Simo Sorce * Red Hat, Inc * New York
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On Mon, Aug 11, 2014 at 09:54:30AM -0700, Michichael Folfsunè wrote:
In our case, when a user calls "sudo ls", I think it is a three-step procedure:
- sudo calls pam_authenticate to authenticate the user
- sudo calls pam_acct_mgmt to make sure that the account is not
locked, that the ldap/gpo policies permit the user to run sudo, etc 3) sudo refers to /etc/sudoers to determine if it can perform the sudo action (i.e. "ls").
The GPO Logon Rights relate to step (2) of this procedure.
Forgive me if I'm misunderstanding, but wouldn't the pam_authenticate attempt an authentication against AD if AD was available, and at that phase determine whether it's locked out or not? In testing, a locked account cannot use sudoers, even if it has a session. If AD isn't available, it'd use the cached password (if enabled), but it wouldn't detect a lockout regardless. Step 2 seems moot outside of that permission check.
You assert that Windows would allow a user to perform remote login (and then access other services, batch jobs, privileged operations) using only the RemoteInteractiveLogonRight. Is your assertion based on actual testing on a Windows client? I ask because this is not my understanding. I would expect that the RemoteInteractiveLogonRight would be consulted when the user used RemoteDesktop on a Windows client to login to the remote Windows server, and that the InteractiveLogonRight (Allow/Deny Local Logon) would be consulted when the user attempted to perform a privileged operation (using RunAs or UAC). However, I haven't actually tested this yet, so it would be useful to know if you have already tested this.
Correct, though Windows makes this is a bit muddy. If a user has rights granted for RemoteInteractive, but rights explicitly denied for Local Interactive (I'm going to refer to it as this just to keep the references clear, I think we all understand that it's InteractiveLogonRight), they can remote desktop into a server and perform all manner of activities and privileged operations. However, with deny Local Interactive in place, if their account is used as the target of a RunAs, the SecondaryLogon service ONLY checks Local Interactive, and they would be denied. They can still make changes to registry, run programs or installers under their privileges, etc; but they can't drop into the "console" session or start a Local Interactive session. UAC runs perfectly fine for the user to elevate their rights (if authorized) using these rights; that's what my personal testing has found. I had to use the explicit denies because of how Windows nests its privileges, the explicit deny supersedes an approval, but only for its respective permission (Local Interactive/Deny Local Interactive).
Are you suggesting that sudo skip all of the pam_acct_mgmt checks (checking for locked accounts, ldap filter policies), or that it skip only the gpo policy check?
Our discussion concluded with the recommendation that it skips the gpo policy check, the authentication handles the lockout check if AD is available.
This is all fine for the AD use-case, but sudo (or any other PAM-aware application for that matter) has no idea what is on the server side, whether it's AD or some home-grown LDAP server. And with LDAP, you typically don't detect the account lockout until the pam_account phase as the authentication only binds as the user DN..
Anyway, this discussion started as a thread about mapping sudo to either InteractiveLogonRight or RemoteLogonRight. It sounds to me that Michichael and Simo are for moving sudo to the Remote bucked. Is that right?
On Mon, Aug 11, 2014 at 12:10:28PM -0400, Simo Sorce wrote:
On Mon, 2014-08-11 at 11:59 -0400, Yassir Elley wrote:
In our case, when a user calls "sudo ls", I think it is a three-step procedure:
- sudo calls pam_authenticate to authenticate the user
- sudo calls pam_acct_mgmt to make sure that the account is not
locked, that the ldap/gpo policies permit the user to run sudo, etc 3) sudo refers to /etc/sudoers to determine if it can perform the sudo action (i.e. "ls").
The GPO Logon Rights relate to step (2) of this procedure.
Except we do not have a logon right in windows that really matches what sudo is/does ... besiodes given sudo does its own authorization checks, what's the point of 2 ?
I assume by 'its own authorization checks', you mean /etc/sudoers, right?
Anyway, this is not something we can influence, can we? /etc/pam.d/sudo includes system-auth on Fedora, so account management is going to be called...
[..]
Are you suggesting that sudo skip all of the pam_acct_mgmt checks (checking for locked accounts, ldap filter policies), or that it skip only the gpo policy check?
Yes I think that is what Michichael and I ended up agreeing is the most sensible solution, given any other would prevent the rightful use of sudo in some situations where it should be allowed.
Simo.
-- Simo Sorce * Red Hat, Inc * New York
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On Mon, 2014-08-11 at 21:06 +0200, Jakub Hrozek wrote:
On Mon, Aug 11, 2014 at 12:10:28PM -0400, Simo Sorce wrote:
On Mon, 2014-08-11 at 11:59 -0400, Yassir Elley wrote:
In our case, when a user calls "sudo ls", I think it is a three-step procedure:
- sudo calls pam_authenticate to authenticate the user
- sudo calls pam_acct_mgmt to make sure that the account is not
locked, that the ldap/gpo policies permit the user to run sudo, etc 3) sudo refers to /etc/sudoers to determine if it can perform the sudo action (i.e. "ls").
The GPO Logon Rights relate to step (2) of this procedure.
Except we do not have a logon right in windows that really matches what sudo is/does ... besiodes given sudo does its own authorization checks, what's the point of 2 ?
I assume by 'its own authorization checks', you mean /etc/sudoers, right?
Yes.
Anyway, this is not something we can influence, can we? /etc/pam.d/sudo includes system-auth on Fedora, so account management is going to be called...
But we can map sudo and sudo-l targets in the gpo code as "always allow".
Simo.
On Mon, Aug 11, 2014 at 03:44:34PM -0400, Simo Sorce wrote:
On Mon, 2014-08-11 at 21:06 +0200, Jakub Hrozek wrote:
On Mon, Aug 11, 2014 at 12:10:28PM -0400, Simo Sorce wrote:
On Mon, 2014-08-11 at 11:59 -0400, Yassir Elley wrote:
In our case, when a user calls "sudo ls", I think it is a three-step procedure:
- sudo calls pam_authenticate to authenticate the user
- sudo calls pam_acct_mgmt to make sure that the account is not
locked, that the ldap/gpo policies permit the user to run sudo, etc 3) sudo refers to /etc/sudoers to determine if it can perform the sudo action (i.e. "ls").
The GPO Logon Rights relate to step (2) of this procedure.
Except we do not have a logon right in windows that really matches what sudo is/does ... besiodes given sudo does its own authorization checks, what's the point of 2 ?
I assume by 'its own authorization checks', you mean /etc/sudoers, right?
Yes.
Anyway, this is not something we can influence, can we? /etc/pam.d/sudo includes system-auth on Fedora, so account management is going to be called...
But we can map sudo and sudo-l targets in the gpo code as "always allow".
Right, we just need to be very careful about documenting this (see the e-mail I just sent) to make sure users of any similar PAM services don't suffer.
Off-hand I can think of Quest -- don't they include a sudo version of their own that might be affected?
On Mon, 2014-08-11 at 21:48 +0200, Jakub Hrozek wrote:
On Mon, Aug 11, 2014 at 03:44:34PM -0400, Simo Sorce wrote:
On Mon, 2014-08-11 at 21:06 +0200, Jakub Hrozek wrote:
On Mon, Aug 11, 2014 at 12:10:28PM -0400, Simo Sorce wrote:
On Mon, 2014-08-11 at 11:59 -0400, Yassir Elley wrote:
In our case, when a user calls "sudo ls", I think it is a three-step procedure:
- sudo calls pam_authenticate to authenticate the user
- sudo calls pam_acct_mgmt to make sure that the account is not
locked, that the ldap/gpo policies permit the user to run sudo, etc 3) sudo refers to /etc/sudoers to determine if it can perform the sudo action (i.e. "ls").
The GPO Logon Rights relate to step (2) of this procedure.
Except we do not have a logon right in windows that really matches what sudo is/does ... besiodes given sudo does its own authorization checks, what's the point of 2 ?
I assume by 'its own authorization checks', you mean /etc/sudoers, right?
Yes.
Anyway, this is not something we can influence, can we? /etc/pam.d/sudo includes system-auth on Fedora, so account management is going to be called...
But we can map sudo and sudo-l targets in the gpo code as "always allow".
Right, we just need to be very careful about documenting this (see the e-mail I just sent) to make sure users of any similar PAM services don't suffer.
Off-hand I can think of Quest -- don't they include a sudo version of their own that might be affected?
There are tons of sudo like apps we need to allow to exist in fact, which is why a tweakable mapping between PAM service names and policies is a requirement IMO.
Simo.
----- Original Message -----
On Mon, 2014-08-11 at 21:48 +0200, Jakub Hrozek wrote:
On Mon, Aug 11, 2014 at 03:44:34PM -0400, Simo Sorce wrote:
On Mon, 2014-08-11 at 21:06 +0200, Jakub Hrozek wrote:
On Mon, Aug 11, 2014 at 12:10:28PM -0400, Simo Sorce wrote:
On Mon, 2014-08-11 at 11:59 -0400, Yassir Elley wrote:
In our case, when a user calls "sudo ls", I think it is a three-step procedure:
- sudo calls pam_authenticate to authenticate the user
- sudo calls pam_acct_mgmt to make sure that the account is not
locked, that the ldap/gpo policies permit the user to run sudo, etc 3) sudo refers to /etc/sudoers to determine if it can perform the sudo action (i.e. "ls").
The GPO Logon Rights relate to step (2) of this procedure.
Except we do not have a logon right in windows that really matches what sudo is/does ... besiodes given sudo does its own authorization checks, what's the point of 2 ?
I assume by 'its own authorization checks', you mean /etc/sudoers, right?
Yes.
Anyway, this is not something we can influence, can we? /etc/pam.d/sudo includes system-auth on Fedora, so account management is going to be called...
But we can map sudo and sudo-l targets in the gpo code as "always allow".
Right, we just need to be very careful about documenting this (see the e-mail I just sent) to make sure users of any similar PAM services don't suffer.
Off-hand I can think of Quest -- don't they include a sudo version of their own that might be affected?
There are tons of sudo like apps we need to allow to exist in fact, which is why a tweakable mapping between PAM service names and policies is a requirement IMO.
Simo.
The current design of the mapping mechanism groups pam service names by LogonRights, by introducing several options of the form:
ad_gpo_map_{interactive, remote_interactive, etc} A comma-separated list of PAM service names for which access control is evaluated with the help of the AD {Interactive, RemoteInteractive, etc} Logon Right. Default: login, su, su-l, gdm, kdm
The current design also has:
ad_gpo_default_rights This option defines how access control is evaluated for PAM services which are not explicitly listed in one of the ad_gpo_map_* options. Allowed values are 'interactive', 'remote_interactive', 'network', 'batch' and 'service' to do the evaluation based on the corresponding AD Logon Right. Additionally 'permit' and 'deny' can be used to either always grant or reject access for PAM services that are not explicitly listed in one of the ad_gpo_map_* options. Default: deny
It sounds like we need two more options to round this out:
ad_gpo_map_permit (string) A comma-separated list of PAM service names for which GPO-based access is always granted, regardless of any AD Logon Rights. Default: sudo, sudo-l
ad_gpo_map_deny (string) A comma-separated list of PAM service names for which GPO-based access is always denied, regardless of any AD Logon Rights. Default: null
Would this address the concerns raised?
Also, do we still want to keep "su" and "su-l" in the Interactive bucket?
Regards, Yassir.
----- Original Message -----
On Mon, Aug 11, 2014 at 03:44:34PM -0400, Simo Sorce wrote:
On Mon, 2014-08-11 at 21:06 +0200, Jakub Hrozek wrote:
On Mon, Aug 11, 2014 at 12:10:28PM -0400, Simo Sorce wrote:
On Mon, 2014-08-11 at 11:59 -0400, Yassir Elley wrote:
In our case, when a user calls "sudo ls", I think it is a three-step procedure:
- sudo calls pam_authenticate to authenticate the user
- sudo calls pam_acct_mgmt to make sure that the account is not
locked, that the ldap/gpo policies permit the user to run sudo, etc 3) sudo refers to /etc/sudoers to determine if it can perform the sudo action (i.e. "ls").
The GPO Logon Rights relate to step (2) of this procedure.
Except we do not have a logon right in windows that really matches what sudo is/does ... besiodes given sudo does its own authorization checks, what's the point of 2 ?
I assume by 'its own authorization checks', you mean /etc/sudoers, right?
Yes.
Anyway, this is not something we can influence, can we? /etc/pam.d/sudo includes system-auth on Fedora, so account management is going to be called...
But we can map sudo and sudo-l targets in the gpo code as "always allow".
Right, we just need to be very careful about documenting this (see the e-mail I just sent) to make sure users of any similar PAM services don't suffer.
Off-hand I can think of Quest -- don't they include a sudo version of their own that might be affected?
I think that adding an ad_gpo_map_permit option (see previous email) would address this, no?
Local admins can certainly add additional pam service names to any of the buckets. For example, they can choose to put quest-sudo in ad_gpo_map_permit or in ad_gpo_map_interactive or whatever. However, this does raise the question of whether we want to allow local admins to *remove* default pam service names from the buckets. In other words, do we want to allow an admin to move the "login" service name (which is in the interactive bucket, by default) to a different bucket (say Network or Batch)? Or do we only want them to be able to provide mappings for service names that have not already been specified as defaults in our code?
Regards, Yassir.
On Mon, Aug 11, 2014 at 04:17:51PM -0400, Yassir Elley wrote:
----- Original Message -----
On Mon, Aug 11, 2014 at 03:44:34PM -0400, Simo Sorce wrote:
On Mon, 2014-08-11 at 21:06 +0200, Jakub Hrozek wrote:
On Mon, Aug 11, 2014 at 12:10:28PM -0400, Simo Sorce wrote:
On Mon, 2014-08-11 at 11:59 -0400, Yassir Elley wrote:
In our case, when a user calls "sudo ls", I think it is a three-step procedure:
- sudo calls pam_authenticate to authenticate the user
- sudo calls pam_acct_mgmt to make sure that the account is not
locked, that the ldap/gpo policies permit the user to run sudo, etc 3) sudo refers to /etc/sudoers to determine if it can perform the sudo action (i.e. "ls").
The GPO Logon Rights relate to step (2) of this procedure.
Except we do not have a logon right in windows that really matches what sudo is/does ... besiodes given sudo does its own authorization checks, what's the point of 2 ?
I assume by 'its own authorization checks', you mean /etc/sudoers, right?
Yes.
Anyway, this is not something we can influence, can we? /etc/pam.d/sudo includes system-auth on Fedora, so account management is going to be called...
But we can map sudo and sudo-l targets in the gpo code as "always allow".
Right, we just need to be very careful about documenting this (see the e-mail I just sent) to make sure users of any similar PAM services don't suffer.
Off-hand I can think of Quest -- don't they include a sudo version of their own that might be affected?
I think that adding an ad_gpo_map_permit option (see previous email) would address this, no?
Local admins can certainly add additional pam service names to any of the buckets. For example, they can choose to put quest-sudo in ad_gpo_map_permit or in ad_gpo_map_interactive or whatever. However, this does raise the question of whether we want to allow local admins to *remove* default pam service names from the buckets. In other words, do we want to allow an admin to move the "login" service name (which is in the interactive bucket, by default) to a different bucket (say Network or Batch)? Or do we only want them to be able to provide mappings for service names that have not already been specified as defaults in our code?
I think overrides would be handy. We can even do something similar as we do with infopipe's attribute list:
Let's consider the ad_gpo_map_permit was set to 'dflsvc' by default. Then:
ad_gpo_map_permit = svc1, svc2 # permit list is explicitly set to svc1, svc2 ad_gpo_map_permit = +svc1 # svc1 is added to the permit list, making the whole list 'dflsvc, svc1' ad_gpo_map_permit = -dflsvc # dflsvc is removed from the permit list, making the list effectivelly empty
See the description of 'user_attributes' in man sssd-ifp for more details.
----- Original Message -----
On Mon, Aug 11, 2014 at 04:17:51PM -0400, Yassir Elley wrote:
----- Original Message -----
On Mon, Aug 11, 2014 at 03:44:34PM -0400, Simo Sorce wrote:
On Mon, 2014-08-11 at 21:06 +0200, Jakub Hrozek wrote:
On Mon, Aug 11, 2014 at 12:10:28PM -0400, Simo Sorce wrote:
On Mon, 2014-08-11 at 11:59 -0400, Yassir Elley wrote: > > In our case, when a user calls "sudo ls", I think it is a > three-step > procedure: > 1) sudo calls pam_authenticate to authenticate the user > 2) sudo calls pam_acct_mgmt to make sure that the account is not > locked, that the ldap/gpo policies permit the user to run sudo, > etc > 3) sudo refers to /etc/sudoers to determine if it can perform the > sudo > action (i.e. "ls"). > > The GPO Logon Rights relate to step (2) of this procedure.
Except we do not have a logon right in windows that really matches what sudo is/does ... besiodes given sudo does its own authorization checks, what's the point of 2 ?
I assume by 'its own authorization checks', you mean /etc/sudoers, right?
Yes.
Anyway, this is not something we can influence, can we? /etc/pam.d/sudo includes system-auth on Fedora, so account management is going to be called...
But we can map sudo and sudo-l targets in the gpo code as "always allow".
Right, we just need to be very careful about documenting this (see the e-mail I just sent) to make sure users of any similar PAM services don't suffer.
Off-hand I can think of Quest -- don't they include a sudo version of their own that might be affected?
I think that adding an ad_gpo_map_permit option (see previous email) would address this, no?
Local admins can certainly add additional pam service names to any of the buckets. For example, they can choose to put quest-sudo in ad_gpo_map_permit or in ad_gpo_map_interactive or whatever. However, this does raise the question of whether we want to allow local admins to *remove* default pam service names from the buckets. In other words, do we want to allow an admin to move the "login" service name (which is in the interactive bucket, by default) to a different bucket (say Network or Batch)? Or do we only want them to be able to provide mappings for service names that have not already been specified as defaults in our code?
I think overrides would be handy. We can even do something similar as we do with infopipe's attribute list:
Let's consider the ad_gpo_map_permit was set to 'dflsvc' by default. Then:
ad_gpo_map_permit = svc1, svc2 # permit list is explicitly set to svc1, svc2 ad_gpo_map_permit = +svc1 # svc1 is added to the permit list, making the whole list 'dflsvc, svc1' ad_gpo_map_permit = -dflsvc # dflsvc is removed from the permit list, making the list effectivelly empty
See the description of 'user_attributes' in man sssd-ifp for more details.
This is cool!
On a separate topic, what should we do if we encounter the same service on multiple maps? For example, if an admin maps a custom service to both 'interactive' as well as 'network', should we consider that to be a misconfiguration. I don't think Microsoft allows this, but I wonder if it makes sense in some linux scenarios. For example, maybe there is a custom pam service and the local admin wants GPO-based access control to be evaluated against both the InteractiveLogonRight and the NetworkLogonRight. But then would we use AND semantics or OR semantics? If he also mapped it to 'permit', would permit override everything else? Same with deny. Yikes. This might get arbitrarily hairy. I propose we just throw a misconfiguration error if we detect a duplicate mapping.
Regards, Yassir.
----- Original Message -----
----- Original Message -----
On Mon, Aug 11, 2014 at 04:17:51PM -0400, Yassir Elley wrote:
----- Original Message -----
On Mon, Aug 11, 2014 at 03:44:34PM -0400, Simo Sorce wrote:
On Mon, 2014-08-11 at 21:06 +0200, Jakub Hrozek wrote:
On Mon, Aug 11, 2014 at 12:10:28PM -0400, Simo Sorce wrote: > On Mon, 2014-08-11 at 11:59 -0400, Yassir Elley wrote: > > > > In our case, when a user calls "sudo ls", I think it is a > > three-step > > procedure: > > 1) sudo calls pam_authenticate to authenticate the user > > 2) sudo calls pam_acct_mgmt to make sure that the account is > > not > > locked, that the ldap/gpo policies permit the user to run sudo, > > etc > > 3) sudo refers to /etc/sudoers to determine if it can perform > > the > > sudo > > action (i.e. "ls"). > > > > The GPO Logon Rights relate to step (2) of this procedure. > > Except we do not have a logon right in windows that really > matches > what > sudo is/does ... besiodes given sudo does its own authorization > checks, > what's the point of 2 ?
I assume by 'its own authorization checks', you mean /etc/sudoers, right?
Yes.
Anyway, this is not something we can influence, can we? /etc/pam.d/sudo includes system-auth on Fedora, so account management is going to be called...
But we can map sudo and sudo-l targets in the gpo code as "always allow".
Right, we just need to be very careful about documenting this (see the e-mail I just sent) to make sure users of any similar PAM services don't suffer.
Off-hand I can think of Quest -- don't they include a sudo version of their own that might be affected?
I think that adding an ad_gpo_map_permit option (see previous email) would address this, no?
Local admins can certainly add additional pam service names to any of the buckets. For example, they can choose to put quest-sudo in ad_gpo_map_permit or in ad_gpo_map_interactive or whatever. However, this does raise the question of whether we want to allow local admins to *remove* default pam service names from the buckets. In other words, do we want to allow an admin to move the "login" service name (which is in the interactive bucket, by default) to a different bucket (say Network or Batch)? Or do we only want them to be able to provide mappings for service names that have not already been specified as defaults in our code?
I think overrides would be handy. We can even do something similar as we do with infopipe's attribute list:
Let's consider the ad_gpo_map_permit was set to 'dflsvc' by default. Then:
ad_gpo_map_permit = svc1, svc2 # permit list is explicitly set to svc1, svc2 ad_gpo_map_permit = +svc1 # svc1 is added to the permit list, making the whole list 'dflsvc, svc1' ad_gpo_map_permit = -dflsvc # dflsvc is removed from the permit list, making the list effectivelly empty
See the description of 'user_attributes' in man sssd-ifp for more details.
This is cool!
On a separate topic, what should we do if we encounter the same service on multiple maps? For example, if an admin maps a custom service to both 'interactive' as well as 'network', should we consider that to be a misconfiguration. I don't think Microsoft allows this, but I wonder if it makes sense in some linux scenarios. For example, maybe there is a custom pam service and the local admin wants GPO-based access control to be evaluated against both the InteractiveLogonRight and the NetworkLogonRight. But then would we use AND semantics or OR semantics? If he also mapped it to 'permit', would permit override everything else? Same with deny. Yikes. This might get arbitrarily hairy. I propose we just throw a misconfiguration error if we detect a duplicate mapping.
Regards, Yassir.
For pam service names in the gpo_map_permit [or gpo_map_deny] bucket, considering that we currently only support the Logon Rights GPO, am I correct in assuming that the gpo code should immediately return EOK [or EACCES] before making any LDAP/SMB calls (but after receiving the service name, of course)?
Regards, Yassir.
hould we just treat the gpo check as a no-op (similar to when it is disabled), or should we go through the
----- Original Message -----
----- Original Message -----
----- Original Message -----
On Mon, Aug 11, 2014 at 04:17:51PM -0400, Yassir Elley wrote:
----- Original Message -----
On Mon, Aug 11, 2014 at 03:44:34PM -0400, Simo Sorce wrote:
On Mon, 2014-08-11 at 21:06 +0200, Jakub Hrozek wrote: > On Mon, Aug 11, 2014 at 12:10:28PM -0400, Simo Sorce wrote: > > On Mon, 2014-08-11 at 11:59 -0400, Yassir Elley wrote: > > > > > > In our case, when a user calls "sudo ls", I think it is a > > > three-step > > > procedure: > > > 1) sudo calls pam_authenticate to authenticate the user > > > 2) sudo calls pam_acct_mgmt to make sure that the account is > > > not > > > locked, that the ldap/gpo policies permit the user to run > > > sudo, > > > etc > > > 3) sudo refers to /etc/sudoers to determine if it can perform > > > the > > > sudo > > > action (i.e. "ls"). > > > > > > The GPO Logon Rights relate to step (2) of this procedure. > > > > Except we do not have a logon right in windows that really > > matches > > what > > sudo is/does ... besiodes given sudo does its own authorization > > checks, > > what's the point of 2 ? > > I assume by 'its own authorization checks', you mean > /etc/sudoers, > right?
Yes.
> Anyway, this is not something we can influence, can we? > /etc/pam.d/sudo > includes system-auth on Fedora, so account management is going to > be > called...
But we can map sudo and sudo-l targets in the gpo code as "always allow".
Right, we just need to be very careful about documenting this (see the e-mail I just sent) to make sure users of any similar PAM services don't suffer.
Off-hand I can think of Quest -- don't they include a sudo version of their own that might be affected?
I think that adding an ad_gpo_map_permit option (see previous email) would address this, no?
Local admins can certainly add additional pam service names to any of the buckets. For example, they can choose to put quest-sudo in ad_gpo_map_permit or in ad_gpo_map_interactive or whatever. However, this does raise the question of whether we want to allow local admins to *remove* default pam service names from the buckets. In other words, do we want to allow an admin to move the "login" service name (which is in the interactive bucket, by default) to a different bucket (say Network or Batch)? Or do we only want them to be able to provide mappings for service names that have not already been specified as defaults in our code?
I think overrides would be handy. We can even do something similar as we do with infopipe's attribute list:
Let's consider the ad_gpo_map_permit was set to 'dflsvc' by default. Then:
ad_gpo_map_permit = svc1, svc2 # permit list is explicitly set to svc1, svc2 ad_gpo_map_permit = +svc1 # svc1 is added to the permit list, making the whole list 'dflsvc, svc1' ad_gpo_map_permit = -dflsvc # dflsvc is removed from the permit list, making the list effectivelly empty
See the description of 'user_attributes' in man sssd-ifp for more details.
This is cool!
On a separate topic, what should we do if we encounter the same service on multiple maps? For example, if an admin maps a custom service to both 'interactive' as well as 'network', should we consider that to be a misconfiguration. I don't think Microsoft allows this, but I wonder if it makes sense in some linux scenarios. For example, maybe there is a custom pam service and the local admin wants GPO-based access control to be evaluated against both the InteractiveLogonRight and the NetworkLogonRight. But then would we use AND semantics or OR semantics? If he also mapped it to 'permit', would permit override everything else? Same with deny. Yikes. This might get arbitrarily hairy. I propose we just throw a misconfiguration error if we detect a duplicate mapping.
Regards, Yassir.
For pam service names in the gpo_map_permit [or gpo_map_deny] bucket, considering that we currently only support the Logon Rights GPO, am I correct in assuming that the gpo code should immediately return EOK [or EACCES] before making any LDAP/SMB calls (but after receiving the service name, of course)?
Regards, Yassir.
hould we just treat the gpo check as a no-op (similar to when it is disabled), or should we go through the
Oops. Pls ignore the sentence fragment immediately above.
Let me also clarify the question.
The following is my proposed table for various combinations of gpo_mode and the category (or bucket) which the service maps to. I am only looking at the permit and deny categories here (not interactive, network, etc)
gpo_mode service_category return_value ==================================================== disabled permit EOK immediately (i.e. before any LDAP/SMB calls) disabled deny EOK immediately ...
enforcing permit EOK immediately ... enforcing deny EACCES immediately ...
permissive permit EOK immediately ... permissive deny EOK immediately ...
Do you agree with the above table?
Regards, Yassir.
On Tue, Aug 26, 2014 at 03:00:27PM -0400, Yassir Elley wrote:
Oops. Pls ignore the sentence fragment immediately above.
Let me also clarify the question.
The following is my proposed table for various combinations of gpo_mode and the category (or bucket) which the service maps to. I am only looking at the permit and deny categories here (not interactive, network, etc)
gpo_mode service_category return_value
disabled permit EOK immediately (i.e. before any LDAP/SMB calls) disabled deny EOK immediately ...
enforcing permit EOK immediately ... enforcing deny EACCES immediately ...
permissive permit EOK immediately ... permissive deny EOK immediately ...
Do you agree with the above table?
Looks good to me. With the permissive setting we should add a DEBUG message, though.
----- Original Message -----
On Tue, Aug 26, 2014 at 03:00:27PM -0400, Yassir Elley wrote:
Oops. Pls ignore the sentence fragment immediately above.
Let me also clarify the question.
The following is my proposed table for various combinations of gpo_mode and the category (or bucket) which the service maps to. I am only looking at the permit and deny categories here (not interactive, network, etc)
gpo_mode service_category return_value
disabled permit EOK immediately (i.e. before any LDAP/SMB calls) disabled deny EOK immediately ...
enforcing permit EOK immediately ... enforcing deny EACCES immediately ...
permissive permit EOK immediately ... permissive deny EOK immediately ...
Do you agree with the above table?
Looks good to me. With the permissive setting we should add a DEBUG message, though. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Agreed.
----- Original Message -----
On Mon, 2014-08-11 at 11:59 -0400, Yassir Elley wrote:
In our case, when a user calls "sudo ls", I think it is a three-step procedure:
- sudo calls pam_authenticate to authenticate the user
- sudo calls pam_acct_mgmt to make sure that the account is not
locked, that the ldap/gpo policies permit the user to run sudo, etc 3) sudo refers to /etc/sudoers to determine if it can perform the sudo action (i.e. "ls").
The GPO Logon Rights relate to step (2) of this procedure.
Except we do not have a logon right in windows that really matches what sudo is/does ... besiodes given sudo does its own authorization checks, what's the point of 2 ?
Isn't the use of RunAs/UAC on Windows similar to sudo (in that they are used for privilege escalation)?
[..]
Are you suggesting that sudo skip all of the pam_acct_mgmt checks (checking for locked accounts, ldap filter policies), or that it skip only the gpo policy check?
Yes I think that is what Michichael and I ended up agreeing is the most sensible solution, given any other would prevent the rightful use of sudo in some situations where it should be allowed.
It's not clear to me which option you are suggesting? Option A: sssd should skip *all* pam_acct_mgmt checks (including locked accounts, ldap filter policies, gpo logon rights) Option B: sssd should skip only the gpo logon rights check, but continue to check for locked accounts and ldap filter policies
Thanks, Yassir.
Anyway, this discussion started as a thread about mapping sudo to either InteractiveLogonRight or RemoteLogonRight. It sounds to me that Michichael and Simo are for moving sudo to the Remote bucked. Is that right?
Negative - we're for removing it from GPO checks entirely.
Isn't the use of RunAs/UAC on Windows similar to sudo (in that they are
used for privilege escalation)?
Yes and no - When you RunAs it checks the target account for Local InteractiveLogon - if you try to RunAs an account that is denied Local InteractiveLogon it'll fail (even if you can remotely log into that account and execute the task as that account). Sudoers is closer to creating process tokens and act as operating system since it does impersonation. RunAs isn't impersonation, it's a secondary logon. UAC does impersonation for admin tokens, but not with the ruleset that sudo has. That's why it's so muddy.
It's not clear to me which option you are suggesting?
My position is option B. An account with only RemoteInteractiveLogon and/or Denied Local InteractiveLogon should still be able to authenticate against sudo and use its functionality.
On Mon, Aug 11, 2014 at 12:17 PM, Yassir Elley yelley@redhat.com wrote:
----- Original Message -----
On Mon, 2014-08-11 at 11:59 -0400, Yassir Elley wrote:
In our case, when a user calls "sudo ls", I think it is a three-step procedure:
- sudo calls pam_authenticate to authenticate the user
- sudo calls pam_acct_mgmt to make sure that the account is not
locked, that the ldap/gpo policies permit the user to run sudo, etc 3) sudo refers to /etc/sudoers to determine if it can perform the sudo action (i.e. "ls").
The GPO Logon Rights relate to step (2) of this procedure.
Except we do not have a logon right in windows that really matches what sudo is/does ... besiodes given sudo does its own authorization checks, what's the point of 2 ?
Isn't the use of RunAs/UAC on Windows similar to sudo (in that they are used for privilege escalation)?
[..]
Are you suggesting that sudo skip all of the pam_acct_mgmt checks (checking for locked accounts, ldap filter policies), or that it skip only the gpo policy check?
Yes I think that is what Michichael and I ended up agreeing is the most sensible solution, given any other would prevent the rightful use of sudo in some situations where it should be allowed.
It's not clear to me which option you are suggesting? Option A: sssd should skip *all* pam_acct_mgmt checks (including locked accounts, ldap filter policies, gpo logon rights) Option B: sssd should skip only the gpo logon rights check, but continue to check for locked accounts and ldap filter policies
Thanks, Yassir. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On Mon, Aug 11, 2014 at 12:28:33PM -0700, Michichael Folfsunè wrote:
Anyway, this discussion started as a thread about mapping sudo to either InteractiveLogonRight or RemoteLogonRight. It sounds to me that Michichael and Simo are for moving sudo to the Remote bucked. Is that right?
Negative - we're for removing it from GPO checks entirely.
Umm I guess this /is/ technically doable although we would need to document the special case very carefully. Also, any custom PAM service built around sudo (one that would maybe include sudo) would break, so proper documentation is really paramount.
I've also reached out to the sudo maintainer to gather his view on sudo calling the account PAM phase to make sure we're not missing something.
On Mon, 2014-08-11 at 21:46 +0200, Jakub Hrozek wrote:
On Mon, Aug 11, 2014 at 12:28:33PM -0700, Michichael Folfsunè wrote:
Anyway, this discussion started as a thread about mapping sudo to either InteractiveLogonRight or RemoteLogonRight. It sounds to me that Michichael and Simo are for moving sudo to the Remote bucked. Is that right?
Negative - we're for removing it from GPO checks entirely.
Umm I guess this /is/ technically doable although we would need to document the special case very carefully. Also, any custom PAM service built around sudo (one that would maybe include sudo) would break, so proper documentation is really paramount.
I've also reached out to the sudo maintainer to gather his view on sudo calling the account PAM phase to make sure we're not missing something.
We need a local mapping mechanism that admins can optionally change.
Known PAM services should have a default if no explicit mapping is done.
Mapping can override known PAM services or add new PAM services mappings.
Mappings would be like: login -> InteractiveLoginRight etc..
however sudo would be: sudo -> @Allow
Simo.
On Mon, 2014-08-11 at 15:17 -0400, Yassir Elley wrote:
----- Original Message -----
On Mon, 2014-08-11 at 11:59 -0400, Yassir Elley wrote:
In our case, when a user calls "sudo ls", I think it is a three-step procedure:
- sudo calls pam_authenticate to authenticate the user
- sudo calls pam_acct_mgmt to make sure that the account is not
locked, that the ldap/gpo policies permit the user to run sudo, etc 3) sudo refers to /etc/sudoers to determine if it can perform the sudo action (i.e. "ls").
The GPO Logon Rights relate to step (2) of this procedure.
Except we do not have a logon right in windows that really matches what sudo is/does ... besiodes given sudo does its own authorization checks, what's the point of 2 ?
Isn't the use of RunAs/UAC on Windows similar to sudo (in that they are used for privilege escalation)?
Not really, they are more like su/su-l than sudo/sudo-l
[..]
Are you suggesting that sudo skip all of the pam_acct_mgmt checks (checking for locked accounts, ldap filter policies), or that it skip only the gpo policy check?
Yes I think that is what Michichael and I ended up agreeing is the most sensible solution, given any other would prevent the rightful use of sudo in some situations where it should be allowed.
It's not clear to me which option you are suggesting? Option A: sssd should skip *all* pam_acct_mgmt checks (including locked accounts, ldap filter policies, gpo logon rights) Option B: sssd should skip only the gpo logon rights check, but continue to check for locked accounts and ldap filter policies
Option C: for sudo/sudo-l assume a local overriding policy of "Allow"
Simo.
On Mon, Aug 11, 2014 at 12:10:28PM -0400, Simo Sorce wrote:
On Mon, 2014-08-11 at 11:59 -0400, Yassir Elley wrote:
In our case, when a user calls "sudo ls", I think it is a three-step procedure:
- sudo calls pam_authenticate to authenticate the user
- sudo calls pam_acct_mgmt to make sure that the account is not
locked, that the ldap/gpo policies permit the user to run sudo, etc 3) sudo refers to /etc/sudoers to determine if it can perform the sudo action (i.e. "ls").
The GPO Logon Rights relate to step (2) of this procedure.
Except we do not have a logon right in windows that really matches what sudo is/does ... besiodes given sudo does its own authorization checks, what's the point of 2 ?
It just occured to me when looking at another SSSD bug that the account check makes sense if the initial login was performed by other means than a PAM-aware login method.
For example, the user might have logged in with SSH keys, bypassing the account phase completely. The user might be expired or locked out. Then, when this user runs sudo, the account phase ensures that running sudo is denied even though he might be present in sudoers..
On Wed, Jul 02, 2014 at 10:47:25AM +0200, Sumit Bose wrote:
Explaining on the logs why access to a service was granted or denied is always a good idea. I guess those messages will fell in the audit-messages category but currently SSSD does not treat audit messages specially. Maybe we should start simple and just add an alias to the DEBUG macro called AUDIT? Later on we can start handling them differently than other debug messages but we will already have (at least for newer code) a label in the code where audit information originates.
I assume that 'later' would be in the context of https://fedorahosted.org/sssd/ticket/2373 and similar tickets.
I wonder if we should add the audit messages more systematically than only the GPO access provider, though..
On Thu, Jul 03, 2014 at 10:17:31AM +0200, Jakub Hrozek wrote:
On Wed, Jul 02, 2014 at 10:47:25AM +0200, Sumit Bose wrote:
Explaining on the logs why access to a service was granted or denied is always a good idea. I guess those messages will fell in the audit-messages category but currently SSSD does not treat audit messages specially. Maybe we should start simple and just add an alias to the DEBUG macro called AUDIT? Later on we can start handling them differently than other debug messages but we will already have (at least for newer code) a label in the code where audit information originates.
I assume that 'later' would be in the context of https://fedorahosted.org/sssd/ticket/2373 and similar tickets.
yes. I said 'later' because there might be quite a number of thing to consider. E.g. we might want to support different audit system/libraries; libaudit has different audit_log_* calls so we have to decide which one to use in which case. Additionally we have to consider how the SSSD audit messages relate to the audit messages which are already send by the PAM stack.
Nevertheless I think it would be a good idea to start tagging messages which we consider worth for audit in new code so that 'later' we can just grep for the tag to see what type of messages we already have.
I wonder if we should add the audit messages more systematically than only the GPO access provider, though..
sure that would be even better. I was just suggesting to start with new code to not create additional work before we know if and to which level we need to support audit in SSSD.
bye, Sumit
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On Wed, 2014-07-02 at 01:45 -0400, Yassir Elley wrote:
----- Original Message -----
On Tue, 2014-07-01 at 01:50 -0400, Yassir Elley wrote:
----- Original Message -----
On Sat, 2014-06-28 at 18:01 -0400, Yassir Elley wrote:
----- Original Message -----
On Sat, 2014-06-28 at 01:20 -0400, Yassir Elley wrote: > > ----- Original Message ----- > > On Thu, 2014-06-26 at 04:54 -0400, Yassir Elley wrote: > > > Hi Simo, > > > > > > I'd like to wrap up this discussion. I propose that we support > > > only > > > the InteractiveLogonRight (for the pam services you mentioned: > > > "login", "*dm, "su*"), and on the RemoteInteractiveLogonRight > > > (for > > > the > > > "ssh" pam service). We should not support the NetworkLogonRight > > > since > > > it is difficult to implement. Do you agree with this proposal? > > > > Well I guess the answer depends on what do you plan to do for pam > > services that are not listed ? > > Do you always deny access ? Always permit ? > > Since we would only support the InteractiveLogonRight and > RemoteInteractiveLogonRight, we would always permit access for > other > pam > services (because they would not be governed by gpo-based access > control, > and this would be clearly documented). > > > > > I think a more reasonable workaround is to define a default type, > > and > > a > > list of mappings. > > > > If a PAM service is explicitly mapped you use that Right to > > decide, > > otherwise the decision falls back to the "default" Right. > > Actually the default right could well be actually > > NetworkLogonRight > > or > > InteractiveLogonRight or something else. As long as you can > > change > > the > > mappings locally through some configuration that would allow the > > admin > > to add mappings according to their needs. Of course strong > > guidance > > on which mappings should be used for specific type of services > > should > > be > > provided. > > > > Simo. > > > > I would prefer an approach which is more predictable for the AD > admin. > If > we limit ourselves to InteractiveLogonRight and > RemoteInteractiveLogonRight, the semantics are very clear (console > login > and remote login), allowing the AD Admin to be confident that any > existing > or future policy files containing those rights would be applied > correctly > and consistently, regardless of whether the machine is running > Linux or > Windows. > > Also, I suspect AD admins would not like per-machine service > mappings > to be > enforced, since that would defeat the purpose of enforcing a > centralized > policy in a consistent manner. When an AD admin made a change to a > LogonRight policy setting, he would have to keep in mind that Linux > machines may use the policy settings in ways that were not intended > by > the > AD admin. For example, it would be problematic if a local admin > decided > to > map "login" to NetworkLogonRight, or if some local admins mapped > "ftp" > to > some LogonRight (but other local admins stayed with the default). > This > would result in inconsistent behavior between different Linux > machines, > and between Linux machines and Windows machines. Indeed, in the > Windows > world, the "local" per-machine GPO is given least priority in case > of > conflict (i.e. ou overrides domain, which overrides site, which > overrides > local). A solution to this problem of consistency would be to have > a > centralized GPO that maps pam services to LogonRights, but I don't > think > we need to implement that in the first release. > > I think limiting ourselves to InteractiveLogonRight and > RemoteInteractiveLogonRight would be less confusing and more > predictable > for AD admins (resulting in a greater likelihood of them deploying > gpo-based access control). They would know that these two > LogonRights > would be enforced with the same semantics on Windows and Linux > machines. > They would also know that other LogonRights would not be enforced > on > Linux > machines. Clean and crisp. > > What do you think?
You make a good argument, but I am not entirely convinced you can avoid a local mapping unless you provide a GPO mapping, because the admin must be able to adjust mappings for new services installed on the box that were not included in the upstream provided lists.
So if you already need to provide a way to augment mappings, you may as well handle all rights with reasonable defaults, and let the admin decide whether they need to change stuff around.
Simo.
Allowing local admins to change stuff from underneath the AD admin's directives seems to violate the GPO philosophy of centralized, consistent application of policy. I don't think AD admins will find the gpo-based access control feature compelling, if it does not fit with their mental model of how GPO is supposed to work.
Sorry but I do not buy this argument. The whole GPO policy can be turned on or off in sssd, so if admins do not control the boxes' sssd.conf file they already know their policies are, at best, advisory.
As you know, LogonRights are existing Windows policy settings (not Linux-specific settings), so we really do have to honor the intent of the settings and the GPO framework.
Indeed, and in order to do that you need to be able to appropriately map arbitrary services.
Having said that, I don't think we necessarily need to have a comprehensive implementation in the first release, especially if we think the GPO mapping is the correct solution (and if we think that we may implement that in a subsequent release).
We do not need the support as a GPO deliverable policy, but you need a local mapping for the feature to be usable/testable IMO.
I think the centralized mapping offered by a future GPO mapping would certainly allay the concerns of AD admins, as the power would remain in their hands and it would be applied consistently. Implementing local mapping now, and then adding a centralized mapping later would delay deployment and would add too much complexity IMO.
Why ? This is exactly the same as overlaying global policy on top of local policy, I honestly do not see it as any more complex than needed.
As for how to deal with new services (in the initial implementation), two ideas come to mind:
- My preference would be that only services included in the upstream
provided lists will be affected by gpo-based access control. Not very extensible, but that's OK if we intend on adding a GPO mapping in a future release.
Upstream runs on multiple OSs and Linux distributions, within those there is already, I bet, enough conflict to make a single upstream list unfeasible, as pam service names are somewhat arbitrary and customized in different way especially for very distro-specific services like login and graphical session managers.
- Alternatively, we could go with a completely different proposal
that would affect all pam services. Specifically, since remote login seems to be an uncommon pam service (we could only come up with "ssh"), we could declare that "ssh" maps to RemoteInteractiveLogonRight, and that *all* other services (including new services, custom services, etc), map to InteractiveLogonRight.
That would be wrong. I suspect one of the services you really want to control, as a windows admin, is samba file services, and those must be mapped to NetworkLogonRight. And NEtworkLogonRight seem to be generally the most sensible default once you exclude the services you know are interactive login shells.
While certainly not ideal (and not my preference), I think AD admins would find this easier to grok than local mappings, as it would be predictable and would allow policy authority to remain centralized, without central directives being manipulated by local admins.
If the admin doesn't grok what services run on a Linux box, they are already doomed I would think. You need at least a passing understanding of the policies you are going to set. We can *definitely* provide a good default set, admins should not be required to provide explicit mappings if the default works for them, but an unchangeable list will severely reduce the utility of the feature.
OK. I forgot that local admins can disable gpo processing, so although AD admins may want centralized control over all domain computers (whether Windows or Linux), they may not be able to get it with this feature. Whether this will be a show-stopper for them remains to be seen. With that in mind, I agree that it makes sense to allow pam services to be mapped to logon rights.
With regard to the default set of mappings, I propose the following (based on previous emails). login/*dm/su* maps to InteractiveLogonRight ssh maps to RemoteInteractiveLogonRight explicit mappings are honored if the service is still unmapped, map it to NetworkLogonRight
I think we can take a page from FreeIPA's configuration, this is the original list of services we provide by default for HBAC:
sshd ftp su login su-l sudo sudo-i gdm gdm-password kdm
To which later updates added: crond vsftpd proftpd pure-ftpd gssftp
Keep in mind that FreeIPA uses also service groups so all the ftp services are grouped under a ftp group.
I think that we can add crond and samba to the first list and use that as the default list.
A few questions for you:
- Does this list make sense?
Mostly, yes.
- Should there be anything special about the default set, or can an
admin re-map services from the default set (i.e. map "ssh" to NetworkLogonRight)?
I would use the following mappings.
InteractiveLogonRight: su, login, su-l, sudo, sudo-i, gdm, gdm-password, kdm RemoteInteractiveLogonRight: sshd NetworkLogonRight: ftp samba BatchLogonRight (?): crond
I am not sure what to use as default fallback for any service that do not match these.
There is a default "remote" service in Fedora, and there is a "other" service which matches any unrecognized service IIRC.
Maybe we could map unknown stuff to ServiceLogonRight which poorly translates to anything useful on Linux I think.
- Should an admin be able to map a service to NULL (indicating that
they don't want this service to be enforced by GPO policy)
So your suggestion would be the unrecognized services would simply be ignored when it comes to GPO enforcing ?
Yes. By essentially providing an opt-in model for pam services (with respect to gpo enforcement), we would be requiring someone to make an informed decision about the service-to-Right mapping (rather than for us to make an arbitrary decision). When an unmapped service is encountered, we would emit a log message (so that the admin can add an explicit mapping, if he forgot to add one). I suspect the distros would be savvy enough to pre-populate the sssd.conf file with distro-specific service mappings, but an individual admin using their own custom pam service might need a nudge.
For example, if an admin forgets to explicitly map a custom service (or doesn't even know he needs to), it would be better for him to receive an "unrecognized service" message in the logs (which would hopefully remind him to add an explicit mapping, after giving it some thought), than for us to arbitrarily map the custom service to some default (which might even result in unintended access denials).
This would be in line with the opt-in model we are using for overall gpo-enforcement (b/c the default is "permissive"). An admin would have to intentionally set the mode to "enforcing", and would have to intentionally provide explicit mappings for non-default services (or even to change a default service mapping).
What do you think?
I generally lean on deny by default, sounds like a saner approach. Especially because admins already have to change it to enforcing manually, so they know what they are doing and it will not come as a surprise.
Simo.
----- Original Message -----
On Wed, 2014-07-02 at 01:45 -0400, Yassir Elley wrote:
----- Original Message -----
On Tue, 2014-07-01 at 01:50 -0400, Yassir Elley wrote:
----- Original Message -----
On Sat, 2014-06-28 at 18:01 -0400, Yassir Elley wrote:
----- Original Message ----- > On Sat, 2014-06-28 at 01:20 -0400, Yassir Elley wrote: > > > > ----- Original Message ----- > > > On Thu, 2014-06-26 at 04:54 -0400, Yassir Elley wrote: > > > > Hi Simo, > > > > > > > > I'd like to wrap up this discussion. I propose that we > > > > support > > > > only > > > > the InteractiveLogonRight (for the pam services you > > > > mentioned: > > > > "login", "*dm, "su*"), and on the > > > > RemoteInteractiveLogonRight > > > > (for > > > > the > > > > "ssh" pam service). We should not support the > > > > NetworkLogonRight > > > > since > > > > it is difficult to implement. Do you agree with this > > > > proposal? > > > > > > Well I guess the answer depends on what do you plan to do for > > > pam > > > services that are not listed ? > > > Do you always deny access ? Always permit ? > > > > Since we would only support the InteractiveLogonRight and > > RemoteInteractiveLogonRight, we would always permit access for > > other > > pam > > services (because they would not be governed by gpo-based > > access > > control, > > and this would be clearly documented). > > > > > > > > I think a more reasonable workaround is to define a default > > > type, > > > and > > > a > > > list of mappings. > > > > > > If a PAM service is explicitly mapped you use that Right to > > > decide, > > > otherwise the decision falls back to the "default" Right. > > > Actually the default right could well be actually > > > NetworkLogonRight > > > or > > > InteractiveLogonRight or something else. As long as you can > > > change > > > the > > > mappings locally through some configuration that would allow > > > the > > > admin > > > to add mappings according to their needs. Of course strong > > > guidance > > > on which mappings should be used for specific type of > > > services > > > should > > > be > > > provided. > > > > > > Simo. > > > > > > > I would prefer an approach which is more predictable for the AD > > admin. > > If > > we limit ourselves to InteractiveLogonRight and > > RemoteInteractiveLogonRight, the semantics are very clear > > (console > > login > > and remote login), allowing the AD Admin to be confident that > > any > > existing > > or future policy files containing those rights would be applied > > correctly > > and consistently, regardless of whether the machine is running > > Linux or > > Windows. > > > > Also, I suspect AD admins would not like per-machine service > > mappings > > to be > > enforced, since that would defeat the purpose of enforcing a > > centralized > > policy in a consistent manner. When an AD admin made a change > > to a > > LogonRight policy setting, he would have to keep in mind that > > Linux > > machines may use the policy settings in ways that were not > > intended > > by > > the > > AD admin. For example, it would be problematic if a local admin > > decided > > to > > map "login" to NetworkLogonRight, or if some local admins > > mapped > > "ftp" > > to > > some LogonRight (but other local admins stayed with the > > default). > > This > > would result in inconsistent behavior between different Linux > > machines, > > and between Linux machines and Windows machines. Indeed, in the > > Windows > > world, the "local" per-machine GPO is given least priority in > > case > > of > > conflict (i.e. ou overrides domain, which overrides site, which > > overrides > > local). A solution to this problem of consistency would be to > > have > > a > > centralized GPO that maps pam services to LogonRights, but I > > don't > > think > > we need to implement that in the first release. > > > > I think limiting ourselves to InteractiveLogonRight and > > RemoteInteractiveLogonRight would be less confusing and more > > predictable > > for AD admins (resulting in a greater likelihood of them > > deploying > > gpo-based access control). They would know that these two > > LogonRights > > would be enforced with the same semantics on Windows and Linux > > machines. > > They would also know that other LogonRights would not be > > enforced > > on > > Linux > > machines. Clean and crisp. > > > > What do you think? > > You make a good argument, but I am not entirely convinced you can > avoid > a local mapping unless you provide a GPO mapping, because the > admin > must > be able to adjust mappings for new services installed on the box > that > were not included in the upstream provided lists. > > So if you already need to provide a way to augment mappings, you > may > as > well handle all rights with reasonable defaults, and let the > admin > decide whether they need to change stuff around. > > Simo. >
Allowing local admins to change stuff from underneath the AD admin's directives seems to violate the GPO philosophy of centralized, consistent application of policy. I don't think AD admins will find the gpo-based access control feature compelling, if it does not fit with their mental model of how GPO is supposed to work.
Sorry but I do not buy this argument. The whole GPO policy can be turned on or off in sssd, so if admins do not control the boxes' sssd.conf file they already know their policies are, at best, advisory.
As you know, LogonRights are existing Windows policy settings (not Linux-specific settings), so we really do have to honor the intent of the settings and the GPO framework.
Indeed, and in order to do that you need to be able to appropriately map arbitrary services.
Having said that, I don't think we necessarily need to have a comprehensive implementation in the first release, especially if we think the GPO mapping is the correct solution (and if we think that we may implement that in a subsequent release).
We do not need the support as a GPO deliverable policy, but you need a local mapping for the feature to be usable/testable IMO.
I think the centralized mapping offered by a future GPO mapping would certainly allay the concerns of AD admins, as the power would remain in their hands and it would be applied consistently. Implementing local mapping now, and then adding a centralized mapping later would delay deployment and would add too much complexity IMO.
Why ? This is exactly the same as overlaying global policy on top of local policy, I honestly do not see it as any more complex than needed.
As for how to deal with new services (in the initial implementation), two ideas come to mind:
- My preference would be that only services included in the
upstream provided lists will be affected by gpo-based access control. Not very extensible, but that's OK if we intend on adding a GPO mapping in a future release.
Upstream runs on multiple OSs and Linux distributions, within those there is already, I bet, enough conflict to make a single upstream list unfeasible, as pam service names are somewhat arbitrary and customized in different way especially for very distro-specific services like login and graphical session managers.
- Alternatively, we could go with a completely different proposal
that would affect all pam services. Specifically, since remote login seems to be an uncommon pam service (we could only come up with "ssh"), we could declare that "ssh" maps to RemoteInteractiveLogonRight, and that *all* other services (including new services, custom services, etc), map to InteractiveLogonRight.
That would be wrong. I suspect one of the services you really want to control, as a windows admin, is samba file services, and those must be mapped to NetworkLogonRight. And NEtworkLogonRight seem to be generally the most sensible default once you exclude the services you know are interactive login shells.
While certainly not ideal (and not my preference), I think AD admins would find this easier to grok than local mappings, as it would be predictable and would allow policy authority to remain centralized, without central directives being manipulated by local admins.
If the admin doesn't grok what services run on a Linux box, they are already doomed I would think. You need at least a passing understanding of the policies you are going to set. We can *definitely* provide a good default set, admins should not be required to provide explicit mappings if the default works for them, but an unchangeable list will severely reduce the utility of the feature.
OK. I forgot that local admins can disable gpo processing, so although AD admins may want centralized control over all domain computers (whether Windows or Linux), they may not be able to get it with this feature. Whether this will be a show-stopper for them remains to be seen. With that in mind, I agree that it makes sense to allow pam services to be mapped to logon rights.
With regard to the default set of mappings, I propose the following (based on previous emails). login/*dm/su* maps to InteractiveLogonRight ssh maps to RemoteInteractiveLogonRight explicit mappings are honored if the service is still unmapped, map it to NetworkLogonRight
I think we can take a page from FreeIPA's configuration, this is the original list of services we provide by default for HBAC:
sshd ftp su login su-l sudo sudo-i gdm gdm-password kdm
To which later updates added: crond vsftpd proftpd pure-ftpd gssftp
Keep in mind that FreeIPA uses also service groups so all the ftp services are grouped under a ftp group.
I think that we can add crond and samba to the first list and use that as the default list.
A few questions for you:
- Does this list make sense?
Mostly, yes.
- Should there be anything special about the default set, or can an
admin re-map services from the default set (i.e. map "ssh" to NetworkLogonRight)?
I would use the following mappings.
InteractiveLogonRight: su, login, su-l, sudo, sudo-i, gdm, gdm-password, kdm RemoteInteractiveLogonRight: sshd NetworkLogonRight: ftp samba BatchLogonRight (?): crond
I am not sure what to use as default fallback for any service that do not match these.
There is a default "remote" service in Fedora, and there is a "other" service which matches any unrecognized service IIRC.
Maybe we could map unknown stuff to ServiceLogonRight which poorly translates to anything useful on Linux I think.
- Should an admin be able to map a service to NULL (indicating that
they don't want this service to be enforced by GPO policy)
So your suggestion would be the unrecognized services would simply be ignored when it comes to GPO enforcing ?
Yes. By essentially providing an opt-in model for pam services (with respect to gpo enforcement), we would be requiring someone to make an informed decision about the service-to-Right mapping (rather than for us to make an arbitrary decision). When an unmapped service is encountered, we would emit a log message (so that the admin can add an explicit mapping, if he forgot to add one). I suspect the distros would be savvy enough to pre-populate the sssd.conf file with distro-specific service mappings, but an individual admin using their own custom pam service might need a nudge.
For example, if an admin forgets to explicitly map a custom service (or doesn't even know he needs to), it would be better for him to receive an "unrecognized service" message in the logs (which would hopefully remind him to add an explicit mapping, after giving it some thought), than for us to arbitrarily map the custom service to some default (which might even result in unintended access denials).
This would be in line with the opt-in model we are using for overall gpo-enforcement (b/c the default is "permissive"). An admin would have to intentionally set the mode to "enforcing", and would have to intentionally provide explicit mappings for non-default services (or even to change a default service mapping).
What do you think?
I generally lean on deny by default, sounds like a saner approach. Especially because admins already have to change it to enforcing manually, so they know what they are doing and it will not come as a surprise.
Simo.
OK. That's a good point. They already have to make a conscious decision to set gpo to enforcing. Let's stick with deny by default, then.
Regards, Yassir.
sssd-devel@lists.fedorahosted.org
-
Jakub Hrozek -
Michichael Folfsunè -
Simo Sorce -
Sumit Bose -
Yassir Elley