Hi André, thank you for your reply.
> -----Original Message----- > From: André Warnier [mailto:a...@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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org Regards, Konstantin Preißer --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
