Re: [OT] Error when using SecurityManager

[Christopher Schultz <ch...@christopherschultz.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Mark,

On 3/21/18 6:24 AM, Mark Thomas wrote:
> On 21/03/18 05:32, Christopher Schultz wrote:
>> All,
>> 
>> I'm exploring running my application under a SecurityManager
> 
> That's brave.

Honestly, it really shouldn't be.

I'm coming to the conclusion that a SecurityManager can really only
limit the damage an application can do to the extent that the
application could already do under normal circumstances.

That sounds idiotic. Let me explain.

In order to prevent the application from making arbitrary network
connections, I can whitelist those connections that are okay. Fine. I
get to specify the hostname (e.g. localhost) and port (e.g. 11211)
that the application is allowed to access.

But since I'm using an exploded WAR file and I don't bother
packaging-up my application into a single JAR file (i.e. I use .class
files in WEB-INF/classes like everyone else), I can't limit those
connections to just my own code.

So, let's say I have an old version of commons-fileupload and my
application unsafely deserializes an untrusted blob. That means that
newly-instantiated code running within my application can reac-hout to
my memcached server and do whatever it wants. Not great.

So in order to get the most benefit from the SecurityManager, I have
to change my application's code (to use PrivilegedActions in places
where it matters) and also its packaging, either to a JAR within the
exploded-WAR, or switch to using a WAR file (which for me wouldn't
actually be that hard).

If I wanted to run more than one web application with different
permissions, this would be an absolute requirement. As it stands, I
have one webapp per Tomcat instance, so this is less of an issue.

What would be really great is if Tomcat could manage the protection
domains such that each web application has its own effective policy,
and wouldn't require the use of PrivilegedActions. I'm not sure if any
of that is even possible... just thinking like a lazy developer who
wants to "add security later" -- the impossible dream.

Thanks,
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlqyYhMACgkQHPApP6U8
pFjGsQ/9FCL3gZW94JySqtMbk+BDCTEfrJuLdlUk9txAO7CiahZ9HdvfAGOGKTzO
hD7sgTpihZ9G6B9/eQXYxr1iGQ1dclQ57See9eDaRazEvNSAhhVSLt7upL/fVstG
YmSmhRz1G+kbJ5K1Urf+345to2g89BdrTH3mR3TUaF8uDyXca2Yd1aWuvbXnlTB5
xLxIAz+K4EBG2UZArOxK1tajkmyhEuA4JA9pl7Zjs0S1FkTMlLwjf6g6Jfli6C5P
NhlTlotXiX47yj7mzTtaJee6t3I+ryUcYuz379SxJmZrJ5I63ey8OscIcIxD/e8k
tz70HuExbZ/cdCvHSZgu3Kld2Ezjq1m9H6a3yCmmGyBOBNn7ggPUxCItR2Id6uEq
gcJ1uaLeZIv8DfK0EouxhHkUP3b4H0x1Fl2Cf6TPFhMzCDcQwdI049eoENwmnOHY
2i0y0APnKcBwSEffbIJoIgYJuAgjNtY6I/ZrKLRTPYnCuN1tgJxbHwKo33JfzCxM
cJ9oIA/l296GCMnUtilecDngWHD5L34Wtp6fYzfxh/zGecU6BZfDMvAN5JT0bwX0
+Y/izmdtHmR5tK9HZLQWCAiFw4hTMzPD7iM9gBfslPKmZxYfCSrsluXZYQQ3iZHW
TtU/iU/breyGRAATICRZiD3EIdP0/px2snihZ8x6yB/iVRWXgTU=
=czHs
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: [OT] Error when using SecurityManager

[Christopher Schultz <ch...@christopherschultz.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Mark,

On 3/21/18 10:39 AM, Mark Thomas wrote:
> On 21/03/18 13:45, Christopher Schultz wrote:
>> Mark,
>> 
>> On 3/21/18 6:24 AM, Mark Thomas wrote:
>>> On 21/03/18 05:32, Christopher Schultz wrote:
>>>> All,
>>>> 
>>>> I'm exploring running my application under a SecurityManager
>> 
>>> That's brave.
>> 
>> Honestly, it really shouldn't be.
>> 
>> I'm coming to the conclusion that a SecurityManager can really
>> only limit the damage an application can do to the extent that
>> the application could already do under normal circumstances.
>> 
>> That sounds idiotic. Let me explain.
>> 
>> In order to prevent the application from making arbitrary
>> network connections, I can whitelist those connections that are
>> okay. Fine. I get to specify the hostname (e.g. localhost) and
>> port (e.g. 11211) that the application is allowed to access.
>> 
>> But since I'm using an exploded WAR file and I don't bother 
>> packaging-up my application into a single JAR file (i.e. I use
>> .class files in WEB-INF/classes like everyone else), I can't
>> limit those connections to just my own code.
> 
> You can limit permissions to just WEB-INF/classes. There is an
> exmaple in catalina.policy in Tomcat 9 at least.

Duh. At first, I did:

grant {
   // stuff my application needs
}

I did that for two reasons:

1. I just wanted to get the application to work. I can narrow-down the
grants after I have an exhaustive list.

2. I wasn't sure all of the code was using PrivilegedActions when
running under a SecurityManager.

So the only danger, then, is having some unforeseen code loaded into
my running web application, writing a .class file into WEB-INF/classes
(theoretically impossible because I'm not allowing writes to that
directory) and then triggering classloading which would then place it
into the security context of WEB-INF/classes.

Then it only has access to some very specific things, but it could
e.g. make a connection to my database (if it could guess a valid set
of credentials) or my e.g. memcached instance (which has no
authentication).

Still, being able to limit the amount of damage that can be done is
attractive.

>> So, let's say I have an old version of commons-fileupload and my 
>> application unsafely deserializes an untrusted blob. That means
>> that newly-instantiated code running within my application can
>> reac-hout to my memcached server and do whatever it wants. Not
>> great.
> 
> Only if you grant the necessary permissions to the
> commons-fileupload WAR. Every piece of code in the stack from the
> call in question until you reach either the top of the stack of a
> privileged action has to have the necessary permission.

Duh. Because of my blanket-grant, this would be possible. But I should
be doing this in a more fine-grained way, which I will be doing.

>> So in order to get the most benefit from the SecurityManager, I
>> have to change my application's code (to use PrivilegedActions in
>> places where it matters)
> 
> Yes. And don't forget design the public API that can call those 
> PrivilegedActions in such a way that they can't be abused.
> Generally, the usual rules about not trusting provided data.

Yes, this is the tough part.

For example, it doesn't make sense to grant "SockerPermission"
"localhost:11211" "connect" to my memcached library. Instead, I'd want
to allow that only for the code in my web application that actually
should be allowed to contact memcached. But of course if I have a
utility class that "gets stuff from memcached", whitelisting that code
also doesn't make much sense, because rogue code could just call that AP
I.

It's a tricky business trying to get the *exact* piece of code the
correct privileges to make the application as close to 100% safe as
possible.

Too fine-grained and it's very difficult to use. Too coarse and you
aren't actually getting any protection.

My goal for the time being is to basically say "if rogue code executes
and can connect to my db/memcached instance, I'm willing to take that
risk" because I have at least made sure it can't connect to some OTHER
service on the internet and become part of a DDOS botnet. And you
can't read my log files and send them to a remote server. And you
can't delete random files on the filesystem.

That's the minimum bar I'm trying to set initially. In the future, I
might get more conservative as I get more familiar with the
capabilities and limits of the SecurityManager and, honestly, the
impacts upon my own code.

>> and also its packaging, either to a JAR within the exploded-WAR,
>> or switch to using a WAR file (which for me wouldn't actually be
>> that hard).
> 
> I don't believe that is necessary.

Well, limiting to a single JAR file might narrow the attack surface.
If the attacker needs to modify my JAR file in order to gain
privileges, it's harder than just dropping a .class file onto the
disk. Or I can even sign the JAR file and require the signature to be
trusted and cut-off that vector.

I can't sign a directory, or even a single .class file. The JAR is the
smallest signable item that could be trusted.

>> If I wanted to run more than one web application with different 
>> permissions, this would be an absolute requirement. As it stands,
>> I have one webapp per Tomcat instance, so this is less of an
>> issue.
>> 
>> What would be really great is if Tomcat could manage the
>> protection domains such that each web application has its own
>> effective policy, and wouldn't require the use of
>> PrivilegedActions. I'm not sure if any of that is even
>> possible... just thinking like a lazy developer who wants to "add
>> security later" -- the impossible dream.
> 
> It could never be as fine-grained as PrivilegedActions which are 
> probably the best solution we have at the moment but it makes
> adding security later very hard work.

Of course. The good news is that I have very few places in my code
where privileged actions are required. Reading system properties,
reading/writing files, and network connections are fairly rare events
or at least they are handled in some specific places.

Some of the privileges need to be given at a coarse-grain such as
"it's okay to read everything in "{webapp}/-" so that my application's
templating library (Velocity) can read the damned templates. I don't
believe Velocity uses PrivilegedActions anywhere so I have to do it
myself (or grant thew whole JVM that privilege, which is what I've
done so far).

I'll keep experimenting to see what I can get done as safely as
possible with as few changes to my application as possible.

Being able to remove that ServletContextListener will be good, because
then I can drop the "allow package access" permission that allows me
to introspect the [Basic]DataSource's close() method (which requires
special permission) and then invoke it (which would already be allowed).

Thanks,
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlqyjNAdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFi8pg//UvxPx8VmzQ6YHZET
hJE5SymXStyITnfxAjioxAhFmcw8Odcq/+px6fz4KdAV7gGEyHR51EIclbYIXLJg
1f2ssdth2dzuNVCeYJzpQVs5XAkhWmXiZaTYczZ3+KTQpI9x6IcP8JByLuqydNrJ
+YadLK8mLq+hiD/8zNESLyY/s9vaVV3m+xAlUkgDz8s2dw0kIioWYGEzhHY/ZXH0
+Xcfr+/tHSfRtbzj9hzKRP6xlo56IcRhbMOmUr41GUuZM2P+EaOPmTTmXWSwwxw7
Ebl1RwTnCwQ4rvTDfsbaKgMMo2VzYghCkVXfiR7YVzlXn7ZC2Sz1YQT9WJhB+Rsa
tkIwxrkvM9QqfCrlctuxf+z+GtNaCKMHmhS9OXAGgEUPTAS/kUzWBJPgtLKv4JZS
kTfF2O+kJYiiws7D3xIO/qOZR+IEQi3D0omroy6c87yQ6y5HQAIIyZqfL93pkQBU
BBcioUtmh5MJuY20jIf+wsNQiglJ83RpwZxEJA4Lann8pGQ6bYyBQBi0EYFbQ42g
TGC5n8R1cYWHRGjAdp2Sx9+cibFzEagA0mASxqs+YnFrApErwVjESd8LX3csUcQl
M6MyrBB5LUuhHGZKlqDP4VPKRw5ZC6skgyElSGU4ePdWD0vaZOKFaO2575iAtMUf
k42bB423ZkPYK2qhQhh2t5SsND4=
=0NCi
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: [OT] Error when using SecurityManager

[Mark Thomas <ma...@apache.org>]

On 21/03/18 13:45, Christopher Schultz wrote:
> Mark,
> 
> On 3/21/18 6:24 AM, Mark Thomas wrote:
>> On 21/03/18 05:32, Christopher Schultz wrote:
>>> All,
>>>
>>> I'm exploring running my application under a SecurityManager
> 
>> That's brave.
> 
> Honestly, it really shouldn't be.
> 
> I'm coming to the conclusion that a SecurityManager can really only
> limit the damage an application can do to the extent that the
> application could already do under normal circumstances.
> 
> That sounds idiotic. Let me explain.
> 
> In order to prevent the application from making arbitrary network
> connections, I can whitelist those connections that are okay. Fine. I
> get to specify the hostname (e.g. localhost) and port (e.g. 11211)
> that the application is allowed to access.
> 
> But since I'm using an exploded WAR file and I don't bother
> packaging-up my application into a single JAR file (i.e. I use .class
> files in WEB-INF/classes like everyone else), I can't limit those
> connections to just my own code.

You can limit permissions to just WEB-INF/classes. There is an exmaple
in catalina.policy in Tomcat 9 at least.

> So, let's say I have an old version of commons-fileupload and my
> application unsafely deserializes an untrusted blob. That means that
> newly-instantiated code running within my application can reac-hout to
> my memcached server and do whatever it wants. Not great.

Only if you grant the necessary permissions to the commons-fileupload
WAR. Every piece of code in the stack from the call in question until
you reach either the top of the stack of a privileged action has to have
the necessary permission.

> So in order to get the most benefit from the SecurityManager, I have
> to change my application's code (to use PrivilegedActions in places
> where it matters)

Yes. And don't forget design the public API that can call those
PrivilegedActions in such a way that they can't be abused. Generally,
the usual rules about not trusting provided data.

> and also its packaging, either to a JAR within the
> exploded-WAR, or switch to using a WAR file (which for me wouldn't
> actually be that hard).

I don't believe that is necessary.

> If I wanted to run more than one web application with different
> permissions, this would be an absolute requirement. As it stands, I
> have one webapp per Tomcat instance, so this is less of an issue.
> 
> What would be really great is if Tomcat could manage the protection
> domains such that each web application has its own effective policy,
> and wouldn't require the use of PrivilegedActions. I'm not sure if any
> of that is even possible... just thinking like a lazy developer who
> wants to "add security later" -- the impossible dream.

It could never be as fine-grained as PrivilegedActions which are
probably the best solution we have at the moment but it makes adding
security later very hard work.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org