You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Konstantin Preißer <kp...@apache.org> on 2013/12/18 15:17:59 UTC
Some security-related questions / enhancements for the Windows Installer
Hi,
while I normally only use the .zip distributions of Tomcat, I just had a look at the Windows Service Installer for Tomcat 8.0.0-RC9.
There are some points related to security which I noticed that could be improved:
1) When installing Tomcat with the Windows Service Installer, it installs by default in "%ProgramFiles%\Apache Software Foundation\Tomcat 8.0". A problem that I see here is that this directory is intended to be the place for binaries of programs that every user which has an account on this Windows installation should be able to use. However, by default, Tomcat places not only binaries, but also data (conf, logs, webapps, work, temp) in this directory (I think it's possible to run Tomcat with a different data directory by setting a different CATALINA_BASE env, but the Installer doesn't seem to do this).
This means e.g. if you have some passwords in your Tomcat config, every other user on the server will be able to read them (or, webapp binaries which you place in the webapps directory, etc.).
Of course, a user which installs a program on the server should know how to secure the data, but I think a Installer should make sure that by default, everything is secure.
So, in this case maybe it could display an option to automatically adjust file permissions, and if it is selected, adjust the directory ACLs of the "Tomcat 8" directory to only allow full access for "NT AUTHORITY\SYSTEM" and "BUILTIN\Administrators", but don't allow read access for ordinary users.
(For Example, if you install Microsoft SQL Server 2012, it will place binaries and data files into C:\Program Files\Microsoft SQL Server, but the setup adjusts the permissions for the DATA directory so that ordinary users can't access it.)
2) By default, the installer sets the Tomcat Service to run under the LocalSystem account which as administrative privileges.
Normally, Tomcat shouldn't run as root/Administrator user for security reasons. I think an alternative would be to run as NetworkService which is a user that exists by default and doesn't have administrative privileges (i.e. it has only normal user rights) [1].
AFAIK, this user can only be used for run services, but it cannot be used with things like the "runas" command so every other user will not be able to access data with NetworkUser privileges. (This is also done e.g. by VisualSVN Server - it runs as NetworkService.)
Note that in this case, if 1) is applied, the installer would need to additionally give full access to the NetworkService for the "Tomcat 8" directory.
3) When running the installer, it asks for the Server Shutdown port which has a value of "8005" by default. However, when running Tomcat as a service, the shutdown port is not needed as the daemon service wrapper implements the logic to shutdown Tomcat. Shouldn't the shutdown port in this case automatically set to "-1" to disable it, for security reasons? Otherwise other users would be able to shutdown Tomcat by connecting to the shutdown port.
What do you think?
[1] http://msdn.microsoft.com/en-us/library/windows/desktop/ms684272%28v=vs.85%29.aspx
Thanks & Regards,
Konstantin Preißer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Some security-related questions / enhancements for the Windows
Installer
Posted by Jeffrey Janner <Je...@PolyDyne.com>.
Konstantin -
Interesting points. See comments in-line.
Jeff
> -----Original Message-----
> From: Konstantin Preißer [mailto:kpreisser@apache.org]
> Sent: Wednesday, December 18, 2013 8:18 AM
> To: 'Tomcat Users List'
> Subject: Some security-related questions / enhancements for the Windows
> Installer
>
> Hi,
>
> while I normally only use the .zip distributions of Tomcat, I just had
> a look at the Windows Service Installer for Tomcat 8.0.0-RC9.
>
> There are some points related to security which I noticed that could be
> improved:
>
> 1) When installing Tomcat with the Windows Service Installer, it
> installs by default in "%ProgramFiles%\Apache Software
> Foundation\Tomcat 8.0". A problem that I see here is that this
> directory is intended to be the place for binaries of programs that
> every user which has an account on this Windows installation should be
> able to use. However, by default, Tomcat places not only binaries, but
> also data (conf, logs, webapps, work, temp) in this directory (I think
> it's possible to run Tomcat with a different data directory by setting
> a different CATALINA_BASE env, but the Installer doesn't seem to do
> this).
>
> This means e.g. if you have some passwords in your Tomcat config, every
> other user on the server will be able to read them (or, webapp binaries
> which you place in the webapps directory, etc.).
> Of course, a user which installs a program on the server should know
> how to secure the data, but I think a Installer should make sure that
> by default, everything is secure.
>
> So, in this case maybe it could display an option to automatically
> adjust file permissions, and if it is selected, adjust the directory
> ACLs of the "Tomcat 8" directory to only allow full access for "NT
> AUTHORITY\SYSTEM" and "BUILTIN\Administrators", but don't allow read
> access for ordinary users.
> (For Example, if you install Microsoft SQL Server 2012, it will place
> binaries and data files into C:\Program Files\Microsoft SQL Server, but
> the setup adjusts the permissions for the DATA directory so that
> ordinary users can't access it.)
>
[Jeff Janner] Not so much of a problem, since in normal usage, only admins should be allowed to login directly into the server, and the Program Files directly is not normally shared to the network.
However, it never hurts to tighten the file system security.
>
> 2) By default, the installer sets the Tomcat Service to run under the
> LocalSystem account which as administrative privileges.
>
> Normally, Tomcat shouldn't run as root/Administrator user for security
> reasons. I think an alternative would be to run as NetworkService which
> is a user that exists by default and doesn't have administrative
> privileges (i.e. it has only normal user rights) [1].
> AFAIK, this user can only be used for run services, but it cannot be
> used with things like the "runas" command so every other user will not
> be able to access data with NetworkUser privileges. (This is also done
> e.g. by VisualSVN Server - it runs as NetworkService.)
>
> Note that in this case, if 1) is applied, the installer would need to
> additionally give full access to the NetworkService for the "Tomcat 8"
> directory.
>
[Jeff Janner] I would argue for using NT AUTHORITY/LocalService instead. The NetworkService account is less secure as it grants access to other systems in the network using the computer's access credentials. The LocalService generally does not grant access to network resources (actually as "anonymous"), so it is the more secure user, and in general, Tomcat should not be accessing remote file systems anyway.
>
> 3) When running the installer, it asks for the Server Shutdown port
> which has a value of "8005" by default. However, when running Tomcat as
> a service, the shutdown port is not needed as the daemon service
> wrapper implements the logic to shutdown Tomcat. Shouldn't the shutdown
> port in this case automatically set to "-1" to disable it, for security
> reasons? Otherwise other users would be able to shutdown Tomcat by
> connecting to the shutdown port.
>
[Jeff Janner] +1
I do this on every install, but most newbies might not know to make the change.
>
> What do you think?
>
[Jeff Janner]
There's a number of additional changes that could be implemented. For example:
The Procrun directory gets created as whatever you put in the Service Name fields, but the display name get set to "Apache Tomcat %release% %service_name%". So, if you install a service name of "DEV" at release 7, and want to keep the name for the 8.0 install and run in parallel, you can't. The display names are OK, but the service name won't be unique and Procrun can't create a separate registry entry for the new version. Perhaps adding the release# to the service name for the Procrun install only would be helpful?
Go ahead and sign the installer executable already. That warning on startup is annoying.
>
> [1] http://msdn.microsoft.com/en-
> us/library/windows/desktop/ms684272%28v=vs.85%29.aspx
>
>
> Thanks & Regards,
> Konstantin Preißer
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
RE: Some security-related questions / enhancements for the Windows Installer
Posted by Konstantin Preißer <kp...@apache.org>.
Hi André,
thanks for your reply.
> -----Original Message-----
> From: André Warnier [mailto:aw@ice-sa.com]
> Sent: Thursday, December 19, 2013 5:17 PM
> To: Tomcat Users List; kpreisser@apache.org
> Subject: Re: Some security-related questions / enhancements for the
> Windows Installer
<snip>
> Hi.
> In the meantime, I checked on my (venerable and also German) Windows XP
> SP3 laptop, and
> the LocalService and NetworkService accounts also exist indeed, although
> under the names
> "NETZWERKDIENST" and "LOKALER DIENST" (as written, capitals and all). So
> Jeffrey was
> right, but you'd probably need to use their SID and find out the non-localised
> names.
>
> I attach a screenshot of the dialog under XP, changing the startup user of the
> Tomcat 6
> service to start under "LOKALER DIENST". The list will probably skip it, but I
> copied you
> directly too.
> (The funny thing is that it tends to imply that the account "LOKALER DIENST"
> under XP,
> does not by default have the permissions required to run a local service..)
Thanks, I recevced it. This message also showed on my system (Server 2012 R2) when changing the user to Local Service.
>
> It could even be started and stopped, without any further file permissions
> changes :
>
> [2013-12-19 17:07:34] [info] Procrun (2.0.6.0) started
> [2013-12-19 17:07:34] [info] Running Service...
> [2013-12-19 17:07:34] [info] Starting service...
> [2013-12-19 17:07:45] [info] Service started in 11500 ms.
> [2013-12-19 17:07:58] [info] Stopping service...
> [2013-12-19 17:08:00] [info] Service stopped.
> [2013-12-19 17:08:00] [info] Run service finished.
> [2013-12-19 17:08:00] [info] Procrun finished.
>
> So personally too, I think it may be a good idea to install Tomcat as
> "LocalService"
> rather than "LocalSystem" in the future.
> If only because it reduces the permissions of Tomcat, and thus theoretically
> the
> possibility of mischief by Tomcat apps.
I also could start Tomcat when changing the user of the service to "Local Service", however without any further file permission changes, Tomcat has no write access to its directory preventing it from working correctly (e.g. it cannot write log files, and Jasper shows "HTTP Status 500 - java.lang.IllegalStateException: No output folder" errors).
So, if Tomcat is set up to run on an non-administrative account like Local Service, one must ajust the file permissions so that this user has full access to the Tomcat directory.
I have not yet looked into how the build of the installer works (res/Tomcat.nsi) (e.g. if it has an option to change file permissions, or if one would need to run icacls.exe directly), and if its possible to specify the user under wich Tomcat should run (as I guess the installation of the service is done by Commons Daemon).
Regards,
Konstantin Preißer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Some security-related questions / enhancements for the Windows
Installer
Posted by André Warnier <aw...@ice-sa.com>.
Konstantin Preißer wrote:
> Sorry for the spam...
>
>> -----Original Message-----
>> From: Konstantin Preißer [mailto:kpreisser@apache.org]
>> Sent: Wednesday, December 18, 2013 8:00 PM
>> To: 'Tomcat Users List'
>> Subject: RE: Some security-related questions / enhancements for the
>> Windows Installer
>>
>>
>>> -----Original Message-----
>>> From: Konstantin Preißer [mailto:kpreisser@apache.org]
>>> Sent: Wednesday, December 18, 2013 6:24 PM
>>>> - the user group "Administrators" is the name in English. In other locales,
>> it
>>> is
>>>> different (French : Administrateurs; German : Administratoren; Spanish:
>>>> Administratores,
>>>> etc.). That can be overcome, but also would complicate the installer.
>>> OK, but I'd think there is a way to use non-local names when modifying file
>>> ACLs (or at least get the localized name).
>> It works e.g. with icacls.exe, but I haven't tried WinAPIs.
>>
>> I was able to grant the "NetworkService" user full access to the folder
>> "C:\testfolder" and subdirectories/files with any of the following commands
>> (on a german Windows Server 2012 R2):
>> 1) icacls testfolder /grant NetworkService:(OI)(CI)(F)
>> 2) icacls testfolder /grant *S-1-5-20:(OI)(CI)(F)
>> 3 icacls testfolder /grant Netzwerkdienst:(OI)(CI)(F)
>>
>> 1) uses the non-local name "NetworkService".
>> 2) uses the numeric SID for NetworkService as described at [1] which is
>> identical on each windows system. However, this SID is only available since
>> Windows Vista and Server 2008.
>
> Sorry, that was wrong - I misread the "Note Added in Windows Vista and Windows Server 2008" description, it belongs to another SID.
> The SID S-1-5-20 for the NetworkService (and related SIDs) also work in Windows Server 2003.
>
>
>> 3) uses a localized account name.
>>
>>
>> So I think localized account names shouldn't be an issue for the installer (but
>> I'm nut sure running icacls.exe is the best way for an Installer to set file
>> permissions - I haven't checked how that works e.g. with WinAPIs).
>>
>> Note however, that using "Administrators" with icacls.exe didn't work for me
>> (the localized name "Administratoren" worked), but the numeric SID of
>> Administrators, S-1-5-32-544, did work.
>
> It also did not work for me with "Local Service", whereas "S-1-5-19" or "Lokaler Dienst" worked.
>
>> [1] http://support.microsoft.com/kb/243330/en-us
>
Hi.
In the meantime, I checked on my (venerable and also German) Windows XP SP3 laptop, and
the LocalService and NetworkService accounts also exist indeed, although under the names
"NETZWERKDIENST" and "LOKALER DIENST" (as written, capitals and all). So Jeffrey was
right, but you'd probably need to use their SID and find out the non-localised names.
I attach a screenshot of the dialog under XP, changing the startup user of the Tomcat 6
service to start under "LOKALER DIENST". The list will probably skip it, but I copied you
directly too.
(The funny thing is that it tends to imply that the account "LOKALER DIENST" under XP,
does not by default have the permissions required to run a local service..)
It could even be started and stopped, without any further file permissions changes :
[2013-12-19 17:07:34] [info] Procrun (2.0.6.0) started
[2013-12-19 17:07:34] [info] Running Service...
[2013-12-19 17:07:34] [info] Starting service...
[2013-12-19 17:07:45] [info] Service started in 11500 ms.
[2013-12-19 17:07:58] [info] Stopping service...
[2013-12-19 17:08:00] [info] Service stopped.
[2013-12-19 17:08:00] [info] Run service finished.
[2013-12-19 17:08:00] [info] Procrun finished.
So personally too, I think it may be a good idea to install Tomcat as "LocalService"
rather than "LocalSystem" in the future.
If only because it reduces the permissions of Tomcat, and thus theoretically the
possibility of mischief by Tomcat apps.
RE: Some security-related questions / enhancements for the Windows Installer
Posted by Konstantin Preißer <kp...@apache.org>.
Sorry for the spam...
> -----Original Message-----
> From: Konstantin Preißer [mailto:kpreisser@apache.org]
> Sent: Wednesday, December 18, 2013 8:00 PM
> To: 'Tomcat Users List'
> Subject: RE: Some security-related questions / enhancements for the
> Windows Installer
>
>
> > -----Original Message-----
> > From: Konstantin Preißer [mailto:kpreisser@apache.org]
> > Sent: Wednesday, December 18, 2013 6:24 PM
>
> > > - the user group "Administrators" is the name in English. In other locales,
> it
> > is
> > > different (French : Administrateurs; German : Administratoren; Spanish:
> > > Administratores,
> > > etc.). That can be overcome, but also would complicate the installer.
> >
> > OK, but I'd think there is a way to use non-local names when modifying file
> > ACLs (or at least get the localized name).
>
> It works e.g. with icacls.exe, but I haven't tried WinAPIs.
>
> I was able to grant the "NetworkService" user full access to the folder
> "C:\testfolder" and subdirectories/files with any of the following commands
> (on a german Windows Server 2012 R2):
> 1) icacls testfolder /grant NetworkService:(OI)(CI)(F)
> 2) icacls testfolder /grant *S-1-5-20:(OI)(CI)(F)
> 3 icacls testfolder /grant Netzwerkdienst:(OI)(CI)(F)
>
> 1) uses the non-local name "NetworkService".
> 2) uses the numeric SID for NetworkService as described at [1] which is
> identical on each windows system. However, this SID is only available since
> Windows Vista and Server 2008.
Sorry, that was wrong - I misread the "Note Added in Windows Vista and Windows Server 2008" description, it belongs to another SID.
The SID S-1-5-20 for the NetworkService (and related SIDs) also work in Windows Server 2003.
> 3) uses a localized account name.
>
>
> So I think localized account names shouldn't be an issue for the installer (but
> I'm nut sure running icacls.exe is the best way for an Installer to set file
> permissions - I haven't checked how that works e.g. with WinAPIs).
>
> Note however, that using "Administrators" with icacls.exe didn't work for me
> (the localized name "Administratoren" worked), but the numeric SID of
> Administrators, S-1-5-32-544, did work.
It also did not work for me with "Local Service", whereas "S-1-5-19" or "Lokaler Dienst" worked.
>
> [1] http://support.microsoft.com/kb/243330/en-us
Regards,
Konstantin Preißer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Some security-related questions / enhancements for the Windows Installer
Posted by Konstantin Preißer <kp...@apache.org>.
> -----Original Message-----
> From: Konstantin Preißer [mailto:kpreisser@apache.org]
> Sent: Wednesday, December 18, 2013 6:24 PM
> > - the user group "Administrators" is the name in English. In other locales, it
> is
> > different (French : Administrateurs; German : Administratoren; Spanish:
> > Administratores,
> > etc.). That can be overcome, but also would complicate the installer.
>
> OK, but I'd think there is a way to use non-local names when modifying file
> ACLs (or at least get the localized name).
It works e.g. with icacls.exe, but I haven't tried WinAPIs.
I was able to grant the "NetworkService" user full access to the folder "C:\testfolder" and subdirectories/files with any of the following commands (on a german Windows Server 2012 R2):
1) icacls testfolder /grant NetworkService:(OI)(CI)(F)
2) icacls testfolder /grant *S-1-5-20:(OI)(CI)(F)
3 icacls testfolder /grant Netzwerkdienst:(OI)(CI)(F)
1) uses the non-local name "NetworkService".
2) uses the numeric SID for NetworkService as described at [1] which is identical on each windows system. However, this SID is only available since Windows Vista and Server 2008.
3) uses a localized account name.
So I think localized account names shouldn't be an issue for the installer (but I'm nut sure running icacls.exe is the best way for an Installer to set file permissions - I haven't checked how that works e.g. with WinAPIs).
Note however, that using "Administrators" with icacls.exe didn't work for me (the localized name "Administratoren" worked), but the numeric SID of Administrators, S-1-5-32-544, did work.
[1] http://support.microsoft.com/kb/243330/en-us
Regards,
Konstantin Preißer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Some security-related questions / enhancements for the Windows Installer
Posted by Konstantin Preißer <kp...@apache.org>.
Hi André,
thank you for your reply.
> -----Original Message-----
> From: André Warnier [mailto:aw@ice-sa.com]
> Sent: Wednesday, December 18, 2013 4:28 PM
> To: Tomcat Users List
> Subject: Re: Some security-related questions / enhancements for the
> Windows Installer
>
> Konstantin Preißer wrote:
> > Hi,
> >
> > while I normally only use the .zip distributions of Tomcat, I just had a look at
> the Windows Service Installer for Tomcat 8.0.0-RC9.
> >
> > There are some points related to security which I noticed that could be
> improved:
> >
> > 1) When installing Tomcat with the Windows Service Installer, it installs by
> default in "%ProgramFiles%\Apache Software Foundation\Tomcat 8.0". A
> problem that I see here is that this directory is intended to be the place for
> binaries of programs that every user which has an account on this Windows
> installation should be able to use. However, by default, Tomcat places not
> only binaries, but also data (conf, logs, webapps, work, temp) in this
> directory (I think it's possible to run Tomcat with a different data directory by
> setting a different CATALINA_BASE env, but the Installer doesn't seem to do
> this).
> >
> > This means e.g. if you have some passwords in your Tomcat config, every
> other user on the server will be able to read them (or, webapp binaries
> which you place in the webapps directory, etc.).
> > Of course, a user which installs a program on the server should know how
> to secure the data, but I think a Installer should make sure that by default,
> everything is secure.
> >
> > So, in this case maybe it could display an option to automatically adjust file
> permissions, and if it is selected, adjust the directory ACLs of the "Tomcat 8"
> directory to only allow full access for "NT AUTHORITY\SYSTEM" and
> "BUILTIN\Administrators", but don't allow read access for ordinary users.
> > (For Example, if you install Microsoft SQL Server 2012, it will place binaries
> and data files into C:\Program Files\Microsoft SQL Server, but the setup
> adjusts the permissions for the DATA directory so that ordinary users can't
> access it.)
> >
> >
> > 2) By default, the installer sets the Tomcat Service to run under the
> LocalSystem account which as administrative privileges.
> >
> > Normally, Tomcat shouldn't run as root/Administrator user for security
> reasons. I think an alternative would be to run as NetworkService which is a
> user that exists by default and doesn't have administrative privileges (i.e. it
> has only normal user rights) [1].
> > AFAIK, this user can only be used for run services, but it cannot be used
> with things like the "runas" command so every other user will not be able to
> access data with NetworkUser privileges. (This is also done e.g. by VisualSVN
> Server - it runs as NetworkService.)
> >
> > Note that in this case, if 1) is applied, the installer would need to
> additionally give full access to the NetworkService for the "Tomcat 8"
> directory.
> >
> >
> > 3) When running the installer, it asks for the Server Shutdown port which
> has a value of "8005" by default. However, when running Tomcat as a service,
> the shutdown port is not needed as the daemon service wrapper
> implements the logic to shutdown Tomcat. Shouldn't the shutdown port in
> this case automatically set to "-1" to disable it, for security reasons?
> Otherwise other users would be able to shutdown Tomcat by connecting to
> the shutdown port.
> >
> >
> > What do you think?
> >
> >
> > [1] http://msdn.microsoft.com/en-
> us/library/windows/desktop/ms684272%28v=vs.85%29.aspx
> >
> >
>
> Konstantin,
>
> while I am not saying that you are wrong in the principle, there are
> nevertheless some
> additional considerations :
> - Tomcat installs as "LocalSystem", not as "Administrator". It is not really the
> same as
> "Administrator".
Yes, with "administrative privileges" I meant especially the file system.
> - the LocalSystem account has extensive privileges on the local machine, but
> it is not a
> domain account and thus has no access to any (Windows) network
> resources. Users cannot
> login as "LocalSystem" nor switch to that account.
Yes. What I meant was, that if Tomcat is running under the System account and Tomcat or one of its web applications had a security vulnerability that allowed a remote attacker to execute code on the local machine, they could access everything so the whole system is compromised. However, if Tomcat runs under NetworkService or LocalService, only the data where this user has access is compromised.
> - the LocalService and NetworkService may indeed by better choices
> nowadays, under recent
> versions of Windows Server. But these accounts do not necessarily exist on
> either older
> Windows versions and/or on Windows workstations. Tomcat is free open-
> source software,
> which often gets installed on older Windows versions or developer
> workstations, so this
> would complicate the installer, if nothing else.
I have never used a Windows Server OS where these accounts didn’t exist (Jeffrey said they exist even on WinXP or server 2003). Even if users were using older Windows versions and cannot upgrade, they probably would install an older version of Tomcat (I would also argue that a new Tomcat version like 8 should specify a more recent windows version like 2008 as minimum requirement).
> - the user group "Administrators" is the name in English. In other locales, it is
> different (French : Administrateurs; German : Administratoren; Spanish:
> Administratores,
> etc.). That can be overcome, but also would complicate the installer.
OK, but I'd think there is a way to use non-local names when modifying file ACLs (or at least get the localized name).
> - in environments where access to the Tomcat directories may be sensitive,
> one would
> usually be talking about "server" computers. To have access to the "Program
> Files"
> directory of such a server, the user would need to be able to login locally to
> the server
> first (that directory is not normally "shared" in the network).
> I would argue that if normal users can do that, you have bigger security issues
> than
> access to the Tomcat conf directory.
Sorry, I don't think I understand you here - why would it be a security issue if an ordinary user (no admin) has read access to the "program files" folder?
I know that hosting tools like Plesk deny access to this folder for hosting users, but AFAIK this is how Windows intends its access right system: Admins have write access to everything, but a normal user has only write access to his userprofile and read access to folders like "Windows" and "program files".
I might be wrong, but isn't this how a terminal server works - you install programs that should be usable by ordinary users to c:\program files, and then let users access the server with RDP (Remote desktop)?
I have also seen at a company that they have windows clients running some services like HTTPD, but you can logon as a normal user. In this case you also have read access to program files, but it would be a problem if you could access any sensitive HTTPD configuration.
> - the shutdown port, as far as I remember, is only accessible from "localhost".
> So in
> order to send a shutdown command, a user would first have to be logged-in
> on the server
> directly. See previous point.
Sure, but if you host websites for other users e.g. with PHP, they can connect from localhoat and shutdown Tomcat.
> - the Tomcat webapps directory is also not normally accessible from outside
> of the server.
> To install applications, one can use the Manager, which is protected by
> Tomcat security.
>
> I am sure that others will come up with other such administrivia.
>
> The Tomcat Windows Installer is not perfect (what ever is?), but it is
> mercifully simple,
> and allows Tomcat to be installed easily on most Windows platforms.
> It could maybe offer an additional option at the beginning, to choose a "more
> secure"
> installation, with its "conf" sub-directory only accessible by local
> Administrators e.g.
> But more options means more complexity means more possibilities of
> screwing up and more
> help needed for novice installers. So there is a trade-off somewhere.
>
> As M.E. would say, "just my 2 cents"..
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
Regards,
Konstantin Preißer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Some security-related questions / enhancements for the Windows
Installer
Posted by Jeffrey Janner <Je...@PolyDyne.com>.
> -----Original Message-----
> From: André Warnier [mailto:aw@ice-sa.com]
> Sent: Wednesday, December 18, 2013 9:28 AM
> To: Tomcat Users List
> Subject: Re: Some security-related questions / enhancements for the
> Windows Installer
>
> Konstantin Preißer wrote:
> > Hi,
> >
> > while I normally only use the .zip distributions of Tomcat, I just
> had a look at the Windows Service Installer for Tomcat 8.0.0-RC9.
> >
> > There are some points related to security which I noticed that could
> be improved:
> >
> > 1) When installing Tomcat with the Windows Service Installer, it
> installs by default in "%ProgramFiles%\Apache Software
> Foundation\Tomcat 8.0". A problem that I see here is that this
> directory is intended to be the place for binaries of programs that
> every user which has an account on this Windows installation should be
> able to use. However, by default, Tomcat places not only binaries, but
> also data (conf, logs, webapps, work, temp) in this directory (I think
> it's possible to run Tomcat with a different data directory by setting
> a different CATALINA_BASE env, but the Installer doesn't seem to do
> this).
> >
> > This means e.g. if you have some passwords in your Tomcat config,
> every other user on the server will be able to read them (or, webapp
> binaries which you place in the webapps directory, etc.).
> > Of course, a user which installs a program on the server should know
> how to secure the data, but I think a Installer should make sure that
> by default, everything is secure.
> >
> > So, in this case maybe it could display an option to automatically
> adjust file permissions, and if it is selected, adjust the directory
> ACLs of the "Tomcat 8" directory to only allow full access for "NT
> AUTHORITY\SYSTEM" and "BUILTIN\Administrators", but don't allow read
> access for ordinary users.
> > (For Example, if you install Microsoft SQL Server 2012, it will place
> > binaries and data files into C:\Program Files\Microsoft SQL Server,
> > but the setup adjusts the permissions for the DATA directory so that
> > ordinary users can't access it.)
> >
> >
> > 2) By default, the installer sets the Tomcat Service to run under the
> LocalSystem account which as administrative privileges.
> >
> > Normally, Tomcat shouldn't run as root/Administrator user for
> security reasons. I think an alternative would be to run as
> NetworkService which is a user that exists by default and doesn't have
> administrative privileges (i.e. it has only normal user rights) [1].
> > AFAIK, this user can only be used for run services, but it cannot be
> > used with things like the "runas" command so every other user will
> not
> > be able to access data with NetworkUser privileges. (This is also
> done
> > e.g. by VisualSVN Server - it runs as NetworkService.)
> >
> > Note that in this case, if 1) is applied, the installer would need to
> additionally give full access to the NetworkService for the "Tomcat 8"
> directory.
> >
> >
> > 3) When running the installer, it asks for the Server Shutdown port
> which has a value of "8005" by default. However, when running Tomcat as
> a service, the shutdown port is not needed as the daemon service
> wrapper implements the logic to shutdown Tomcat. Shouldn't the shutdown
> port in this case automatically set to "-1" to disable it, for security
> reasons? Otherwise other users would be able to shutdown Tomcat by
> connecting to the shutdown port.
> >
> >
> > What do you think?
> >
> >
> > [1]
> > http://msdn.microsoft.com/en-
> us/library/windows/desktop/ms684272%28v=v
> > s.85%29.aspx
> >
> >
>
> Konstantin,
>
> while I am not saying that you are wrong in the principle, there are
> nevertheless some additional considerations :
> - Tomcat installs as "LocalSystem", not as "Administrator". It is not
> really the same as "Administrator".
> - the LocalSystem account has extensive privileges on the local
> machine, but it is not a domain account and thus has no access to any
> (Windows) network resources. Users cannot login as "LocalSystem" nor
> switch to that account.
> - the LocalService and NetworkService may indeed by better choices
> nowadays, under recent versions of Windows Server. But these accounts
> do not necessarily exist on either older Windows versions and/or on
> Windows workstations. Tomcat is free open-source software, which often
> gets installed on older Windows versions or developer workstations, so
> this would complicate the installer, if nothing else.
[Jeff Janner]
All 3 are available at least as far back as Windows XP and Server 2000.
If you are working on anything older than that, it's time to upgrade.
Also, I'm pretty sure that they are all available on workstation as well as server.
> - the user group "Administrators" is the name in English. In other
> locales, it is different (French : Administrateurs; German :
> Administratoren; Spanish: Administratores, etc.). That can be overcome,
> but also would complicate the installer.
> - in environments where access to the Tomcat directories may be
> sensitive, one would usually be talking about "server" computers. To
> have access to the "Program Files"
> directory of such a server, the user would need to be able to login
> locally to the server first (that directory is not normally "shared" in
> the network).
> I would argue that if normal users can do that, you have bigger
> security issues than access to the Tomcat conf directory.
> - the shutdown port, as far as I remember, is only accessible from
> "localhost". So in order to send a shutdown command, a user would first
> have to be logged-in on the server directly. See previous point.
[Jeff Janner] Correct, but still only a minor change that would be an improvement.
> - the Tomcat webapps directory is also not normally accessible from
> outside of the server.
> To install applications, one can use the Manager, which is protected
> by Tomcat security.
>
> I am sure that others will come up with other such administrivia.
>
> The Tomcat Windows Installer is not perfect (what ever is?), but it is
> mercifully simple, and allows Tomcat to be installed easily on most
> Windows platforms.
> It could maybe offer an additional option at the beginning, to choose a
> "more secure"
> installation, with its "conf" sub-directory only accessible by local
> Administrators e.g.
> But more options means more complexity means more possibilities of
> screwing up and more help needed for novice installers. So there is a
> trade-off somewhere.
>
> As M.E. would say, "just my 2 cents"..
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: Some security-related questions / enhancements for the Windows
Installer
Posted by André Warnier <aw...@ice-sa.com>.
Konstantin Preißer wrote:
> Hi,
>
> while I normally only use the .zip distributions of Tomcat, I just had a look at the Windows Service Installer for Tomcat 8.0.0-RC9.
>
> There are some points related to security which I noticed that could be improved:
>
> 1) When installing Tomcat with the Windows Service Installer, it installs by default in "%ProgramFiles%\Apache Software Foundation\Tomcat 8.0". A problem that I see here is that this directory is intended to be the place for binaries of programs that every user which has an account on this Windows installation should be able to use. However, by default, Tomcat places not only binaries, but also data (conf, logs, webapps, work, temp) in this directory (I think it's possible to run Tomcat with a different data directory by setting a different CATALINA_BASE env, but the Installer doesn't seem to do this).
>
> This means e.g. if you have some passwords in your Tomcat config, every other user on the server will be able to read them (or, webapp binaries which you place in the webapps directory, etc.).
> Of course, a user which installs a program on the server should know how to secure the data, but I think a Installer should make sure that by default, everything is secure.
>
> So, in this case maybe it could display an option to automatically adjust file permissions, and if it is selected, adjust the directory ACLs of the "Tomcat 8" directory to only allow full access for "NT AUTHORITY\SYSTEM" and "BUILTIN\Administrators", but don't allow read access for ordinary users.
> (For Example, if you install Microsoft SQL Server 2012, it will place binaries and data files into C:\Program Files\Microsoft SQL Server, but the setup adjusts the permissions for the DATA directory so that ordinary users can't access it.)
>
>
> 2) By default, the installer sets the Tomcat Service to run under the LocalSystem account which as administrative privileges.
>
> Normally, Tomcat shouldn't run as root/Administrator user for security reasons. I think an alternative would be to run as NetworkService which is a user that exists by default and doesn't have administrative privileges (i.e. it has only normal user rights) [1].
> AFAIK, this user can only be used for run services, but it cannot be used with things like the "runas" command so every other user will not be able to access data with NetworkUser privileges. (This is also done e.g. by VisualSVN Server - it runs as NetworkService.)
>
> Note that in this case, if 1) is applied, the installer would need to additionally give full access to the NetworkService for the "Tomcat 8" directory.
>
>
> 3) When running the installer, it asks for the Server Shutdown port which has a value of "8005" by default. However, when running Tomcat as a service, the shutdown port is not needed as the daemon service wrapper implements the logic to shutdown Tomcat. Shouldn't the shutdown port in this case automatically set to "-1" to disable it, for security reasons? Otherwise other users would be able to shutdown Tomcat by connecting to the shutdown port.
>
>
> What do you think?
>
>
> [1] http://msdn.microsoft.com/en-us/library/windows/desktop/ms684272%28v=vs.85%29.aspx
>
>
Konstantin,
while I am not saying that you are wrong in the principle, there are nevertheless some
additional considerations :
- Tomcat installs as "LocalSystem", not as "Administrator". It is not really the same as
"Administrator".
- the LocalSystem account has extensive privileges on the local machine, but it is not a
domain account and thus has no access to any (Windows) network resources. Users cannot
login as "LocalSystem" nor switch to that account.
- the LocalService and NetworkService may indeed by better choices nowadays, under recent
versions of Windows Server. But these accounts do not necessarily exist on either older
Windows versions and/or on Windows workstations. Tomcat is free open-source software,
which often gets installed on older Windows versions or developer workstations, so this
would complicate the installer, if nothing else.
- the user group "Administrators" is the name in English. In other locales, it is
different (French : Administrateurs; German : Administratoren; Spanish: Administratores,
etc.). That can be overcome, but also would complicate the installer.
- in environments where access to the Tomcat directories may be sensitive, one would
usually be talking about "server" computers. To have access to the "Program Files"
directory of such a server, the user would need to be able to login locally to the server
first (that directory is not normally "shared" in the network).
I would argue that if normal users can do that, you have bigger security issues than
access to the Tomcat conf directory.
- the shutdown port, as far as I remember, is only accessible from "localhost". So in
order to send a shutdown command, a user would first have to be logged-in on the server
directly. See previous point.
- the Tomcat webapps directory is also not normally accessible from outside of the server.
To install applications, one can use the Manager, which is protected by Tomcat security.
I am sure that others will come up with other such administrivia.
The Tomcat Windows Installer is not perfect (what ever is?), but it is mercifully simple,
and allows Tomcat to be installed easily on most Windows platforms.
It could maybe offer an additional option at the beginning, to choose a "more secure"
installation, with its "conf" sub-directory only accessible by local Administrators e.g.
But more options means more complexity means more possibilities of screwing up and more
help needed for novice installers. So there is a trade-off somewhere.
As M.E. would say, "just my 2 cents"..
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org