SSPCPP-961

Rod Widdowson rdw at steadingsoftware.com
Wed Mar 8 11:11:36 UTC 2023


I'll comment on the technical side.  But I'll leave it to Scott to speak to the project's position with respect to security and this
issue..

> I was looking at the changes from the subject issue. I initially would've expected the ACL to only be set on a fresh install where
the
> directories did not exist, but empirically I see that a patch install over an existing deployment appears to update the ACL as
well?

Sigh.  One would have thought that a CreateDirectory operation would only apply to created directories.  "Do not mess with WiX and
the Windows installer for they are subtle and quick to anger".  

I will say that AFAICS the ability to affects the ACLS is highly limited in the installer (why not add the ACE, rather than replace
the ACL?) and without writing our own extension (just say no) I don't see a way of doing the right thing, just a series of slightly
less wrong ones.  But TBH the whole area of ACLS, and SACLS and DACLS and ownership gets very complicated very quickly.

Anyway, and subject to the project team's agreement,  I think this might be fixable if you want to pop in a JIRA case.  At the same
time I suspect that we would add a way to supress any of this ACL mucking about..  Meantime I will point you to the WEBSERVER_USER
property.

> Also, the ACLs are only set on C:\opt\shibboleth-sp, not C:\opt which appears to still maintain modify permissions for all
authorized
> users? 

In theory at least (see the comment above) we do not own that directory.  Also in general top level folders are already under a
restricted ACL (again in theory).  A  (different) JIRA case would allow us to discuss and eventually address this.  Of course going
beyond that you could also in theory change the symbolic link that is "C:" to point to another disk partition.  Where do you stop?

> Although when I tried to do so, I was unable to rename C:\opt, as it said "The action can't be completed because the folder or a
file in
> it is open in another program". I'm not sure how in the problem report the reporter was able to rename the sbin64 directory, 

You have to stop any process which has executables open in that tree (mostly shibd_default).  Let us not worry for the time being
that the privs to say "sc stop shibd_default" may well be pretty close to the privs to say "sc config shid_default binpath=
c:\malign.exe"

> Thanks...
Thank you.  This sort of feedback is always useful.

Rod



More information about the users mailing list