Re: SPNEGO GSSCaller {UNKNOWN} No Delegated Creds

[Michael Osipov]

On 2024/05/02 19:20:59 Tom Delaney wrote:
> Hi All,
> 
> Sorry for the duplicate requests. The first one was accidentally flagged
> for Google's new Confidential Mode which happened to be flagged.
> I have a red hat 9.2 server hosting a web application on a single instance
> of Apache Tomcat. This instance is behind an apache HTTP server on version
> 2.4.57.The application is hosted on Tomcat 9.0.54.
> 
> Domain: subdomain.domain.com
> Site: devexample.domain.com
> 
> URL hit: https://example.subdomain.domain.com/webclient/
> exclient.jsp
> 
> *I keep getting this in the Tomcat Logs when accessing the application:*
> *>>> Constrained deleg from GSSCaller{UNKNOWN}*

You should first try to describe what you are trying to achieve and not what 
the debug output is. The debug message comes from: 
https://github.com/openjdk/jdk8u-dev/blob/6b53212ef78ad50f9eede829c5ff87cadcdb434b/jdk/src/share/classes/sun/security/jgss/krb5/Krb5Context.java#L540
 The message is obviously caused by this call: 
https://github.com/openjdk/jdk8u-dev/blob/6b53212ef78ad50f9eede829c5ff87cadcdb434b/jdk/src/share/classes/sun/security/jgss/krb5/Krb5Context.java#L254-L263

S4U is tried, but not configured for that account. Totally fine.

BTW: The filter you use isn't from us.

M

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

Re: Package URLs for Apache Tomcat distributions

[Arnout Engelen]

Thanks for bringing this up! The topic of software (artifact)
identification is indeed a tricky one. CPEs have long been the main
contender, but are not great for the SBOM (and 'vulnerability scanning'
based on SBOMs) use case because CPE allocations need through the NVD CPE
team, and generally are only allocated when the project has its first CVE
vulnerability advisory.

Indeed purl's seem like a promising candidate. The use of several 'purl
types' and piggy-backing on existing popular distribution mechanisms help
it scale.

A possible limitation of having the different 'purl types' is that a single
piece of software may have a name in different namespaces: if a
vulnerability is found in Tomcat, should its advisory refer to
"pkg:github/apache/tomcat", or "pkg:maven/org.apache.tomcat/tomcat", or a
to-be-introduced "apache" or "asf" type? All of them? Should there be a
database of "equivalences" or similar relationships between purls for the
same software under different types?

I've actually prototyped an approach for an 'asf' purl type based on an
Apache identifier registry in
https://lists.apache.org/thread/ddl2lnm2mbm0vm62yxlwyh3cbv47wyr7. However,
that somewhat goes against the purl design where the purl can ideally be
'inferred from context' rather than explicitly 'defined'. For example for
artifacts that are typically published to Maven Central, it currently
doesn't seem to be the convention to use any other purl type: the CycloneDX
Maven plugin pretty much hard-codes the 'maven' type (
https://github.com/CycloneDX/cyclonedx-maven-plugin/blob/master/src/main/java/org/cyclonedx/maven/DefaultModelConverter.java#L147).
Should we then not have an 'apache'/'asf' type at all? Or only for
artifacts that cannot be described using any other type? Or for all
artifacts, making an 'equivalences database' a mandatory part of any
vulnerability scanner?


Kind regards,

Arnout

On Mon, Apr 15, 2024 at 2:20 PM von Loewenstein, Jan
 wrote:

> Hi all,
>
> I recently started a discussion about pURLs as package identifier on the
> Tomcat mailing list and it was brought up, that this might be a broader
> topic to be discussed here.
>
> Best regards
> Jan
>
> From: Thomas Hoffmann (Speed4Trade GmbH)
> 
> Date: Monday, 15. April 2024 at 13:14
> To: Tomcat Users List 
> Subject: AW: Package URLs for Apache Tomcat distributions
> [You don't often get email from thomas.hoffm...@speed4trade.com.invalid.
> Learn why this is important at
> https://aka.ms/LearnAboutSenderIdentification ]
>
> > On 11/04/2024 16:52, von Loewenstein, Jan wrote:
> > > Hi folks,
> > >
> > > I am part of the Paketo community, and we are providing Cloud Native
> > Buildpacks to create container images with – amongst other technologies –
> > Apache Tomcat and Apache TomEE as application runtimes.
> > >
> > > One of the features of Cloud Native Buildpacks is that images come with
> > Software-Bill-of-Material. When installing Apache Tomcat, we issue the
> > following CPE and pURL to the SBOM:
> > >
> > >1.  cpe:2.3:a:apache:tomcat:10.1.20:*:*:*:*:*:*:*
> > >2.  pkg:generic/apache-tomcat@10.1.20
> > >
> > > The former should be the right one for users to find relevant CVEs in
> > > e.g. the nvd.nist.gov. The latter however is made up and will likely
> > > not lead to any findings on e.g.
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fosv.dev%2F&data=05%7C02%7Cjan.von.loewenstein%40sap.com%7Cb85c9c7b0ef84a12888a08dc5d3d36f8%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638487764973925741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C4%7C%7C%7C&sdata=THsJsmmmf%2BYnOFsfX2ET%2B9qosC%2F3%2BTmn73piJBppidA%3D&reserved=0
> 
> > >
> > > Now I am wondering if you report Tomcat vulnerabilities under any pURL
> and
> > which one that would be.
> >
> > We don't.
> >
> > > There is a proposal<
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpackage-url%2Fpurl-&data=05%7C02%7Cjan.von.loewenstein%40sap.com%7Cb85c9c7b0ef84a12888a08dc5d3d36f8%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638487764973934423%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C4%7C%7C%7C&sdata=qob5tUw6pGi%2F3crVP%2BlA%2BSqiAo4I2vWTMArkC%2F4%2BtXc%3D&reserved=0
> > spec/blob/master/PURL-TYPES.rst#other-candidate-types-to-define> to
> > introduce `pkg:apache` as a namespace, which would open up
> > `pkg:apache/tomcat@10.1.20` as a canonical pURL.
> >
> > That is a foundation wide decision and not one the Tomcat project can
> make
> > unilaterally. That is probably a topic for security-
> > disc...@community.apache.org where pURL has already been touched on this
> > thread:
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2F7hs5ooqhfozmhlvq24k5xztzn1nwp9yv&data=05%7C02%7Cjan.von.loewenstein%40sap.com%7Cb85c9c7b0ef84a12888a08dc5d3d36f8%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%

Re: Package URLs for Apache Tomcat distributions

[Lars Francke]

Just as an FYI that we established an official TG (Task Group) for
PURL in yesterdays Ecma TC54 (CycloneDX) meeting:
https://docs.google.com/document/d/1BkBd4PRhpP_u1WO_GueYB89vehT_HPKgFMMfbTuKWV4/edit#heading=h.si64e7edhupe
This will take a bit to get set up but this may be something some
people here may be interested in participating in?

Cheers,
Lars

On Fri, May 3, 2024 at 2:28 PM Arnout Engelen  wrote:
>
> Thanks for bringing this up! The topic of software (artifact)
> identification is indeed a tricky one. CPEs have long been the main
> contender, but are not great for the SBOM (and 'vulnerability scanning'
> based on SBOMs) use case because CPE allocations need through the NVD CPE
> team, and generally are only allocated when the project has its first CVE
> vulnerability advisory.
>
> Indeed purl's seem like a promising candidate. The use of several 'purl
> types' and piggy-backing on existing popular distribution mechanisms help
> it scale.
>
> A possible limitation of having the different 'purl types' is that a single
> piece of software may have a name in different namespaces: if a
> vulnerability is found in Tomcat, should its advisory refer to
> "pkg:github/apache/tomcat", or "pkg:maven/org.apache.tomcat/tomcat", or a
> to-be-introduced "apache" or "asf" type? All of them? Should there be a
> database of "equivalences" or similar relationships between purls for the
> same software under different types?
>
> I've actually prototyped an approach for an 'asf' purl type based on an
> Apache identifier registry in
> https://lists.apache.org/thread/ddl2lnm2mbm0vm62yxlwyh3cbv47wyr7. However,
> that somewhat goes against the purl design where the purl can ideally be
> 'inferred from context' rather than explicitly 'defined'. For example for
> artifacts that are typically published to Maven Central, it currently
> doesn't seem to be the convention to use any other purl type: the CycloneDX
> Maven plugin pretty much hard-codes the 'maven' type (
> https://github.com/CycloneDX/cyclonedx-maven-plugin/blob/master/src/main/java/org/cyclonedx/maven/DefaultModelConverter.java#L147).
> Should we then not have an 'apache'/'asf' type at all? Or only for
> artifacts that cannot be described using any other type? Or for all
> artifacts, making an 'equivalences database' a mandatory part of any
> vulnerability scanner?
>
>
> Kind regards,
>
> Arnout
>
> On Mon, Apr 15, 2024 at 2:20 PM von Loewenstein, Jan
>  wrote:
>
> > Hi all,
> >
> > I recently started a discussion about pURLs as package identifier on the
> > Tomcat mailing list and it was brought up, that this might be a broader
> > topic to be discussed here.
> >
> > Best regards
> > Jan
> >
> > From: Thomas Hoffmann (Speed4Trade GmbH)
> > 
> > Date: Monday, 15. April 2024 at 13:14
> > To: Tomcat Users List 
> > Subject: AW: Package URLs for Apache Tomcat distributions
> > [You don't often get email from thomas.hoffm...@speed4trade.com.invalid.
> > Learn why this is important at
> > https://aka.ms/LearnAboutSenderIdentification ]
> >
> > > On 11/04/2024 16:52, von Loewenstein, Jan wrote:
> > > > Hi folks,
> > > >
> > > > I am part of the Paketo community, and we are providing Cloud Native
> > > Buildpacks to create container images with – amongst other technologies –
> > > Apache Tomcat and Apache TomEE as application runtimes.
> > > >
> > > > One of the features of Cloud Native Buildpacks is that images come with
> > > Software-Bill-of-Material. When installing Apache Tomcat, we issue the
> > > following CPE and pURL to the SBOM:
> > > >
> > > >1.  cpe:2.3:a:apache:tomcat:10.1.20:*:*:*:*:*:*:*
> > > >2.  pkg:generic/apache-tomcat@10.1.20
> > > >
> > > > The former should be the right one for users to find relevant CVEs in
> > > > e.g. the nvd.nist.gov. The latter however is made up and will likely
> > > > not lead to any findings on e.g.
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fosv.dev%2F&data=05%7C02%7Cjan.von.loewenstein%40sap.com%7Cb85c9c7b0ef84a12888a08dc5d3d36f8%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638487764973925741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C4%7C%7C%7C&sdata=THsJsmmmf%2BYnOFsfX2ET%2B9qosC%2F3%2BTmn73piJBppidA%3D&reserved=0
> > 
> > > >
> > > > Now I am wondering if you report Tomcat vulnerabilities under any pURL
> > and
> > > which one that would be.
> > >
> > > We don't.
> > >
> > > > There is a proposal<
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpackage-url%2Fpurl-&data=05%7C02%7Cjan.von.loewenstein%40sap.com%7Cb85c9c7b0ef84a12888a08dc5d3d36f8%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638487764973934423%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C4%7C%7C%7C&sdata=qob5tUw6pGi%2F3crVP%2BlA%2BSqiAo4I2vWTMArkC%2F4%2BtXc%3D&reserved=0
> > > spec/blob/master/PURL-TYPES.rst#other-candidate-types-to-define> to
> > > introduce `pkg:a

Re: Package URLs for Apache Tomcat distributions

[von Loewenstein, Jan]

Hi,

I think in the end it boils down to something very simple (and probably very 
complicated from another perpsective 😉): Can the id of a piece of software be 
used to find vulnerabilities?

In the context of this mailing list and the example you brought up with 
defaulting to pkg:maven, the important question is: Will a security reseacher 
finding a vulnerability in e.g. the catalina.sh script - that’s probably not 
published to Maven Central (?) – report this against 
pkg:maven/org.apache.tomcat/tomcat, which points to artefacts that are 
published to Maven Central?

Best regards
Jan

From: Arnout Engelen 
Date: Friday, 3. May 2024 at 14:28
To: security-disc...@community.apache.org 

Cc: Tomcat Users List 
Subject: Re: Package URLs for Apache Tomcat distributions
[You don't often get email from enge...@apache.org. Learn why this is important 
at https://aka.ms/LearnAboutSenderIdentification ]

Thanks for bringing this up! The topic of software (artifact)
identification is indeed a tricky one. CPEs have long been the main
contender, but are not great for the SBOM (and 'vulnerability scanning'
based on SBOMs) use case because CPE allocations need through the NVD CPE
team, and generally are only allocated when the project has its first CVE
vulnerability advisory.

Indeed purl's seem like a promising candidate. The use of several 'purl
types' and piggy-backing on existing popular distribution mechanisms help
it scale.

A possible limitation of having the different 'purl types' is that a single
piece of software may have a name in different namespaces: if a
vulnerability is found in Tomcat, should its advisory refer to
"pkg:github/apache/tomcat", or "pkg:maven/org.apache.tomcat/tomcat", or a
to-be-introduced "apache" or "asf" type? All of them? Should there be a
database of "equivalences" or similar relationships between purls for the
same software under different types?

I've actually prototyped an approach for an 'asf' purl type based on an
Apache identifier registry in
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2Fddl2lnm2mbm0vm62yxlwyh3cbv47wyr7&data=05%7C02%7Cjan.von.loewenstein%40sap.com%7C7c65d1d7e6434f1ac5bb08dc6b6c81fd%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638503360979632497%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2BPSnqhRXL7gKYvmbCT5N3kuTX0x1stgLMDjWYztx5Hs%3D&reserved=0.
 However,
that somewhat goes against the purl design where the purl can ideally be
'inferred from context' rather than explicitly 'defined'. For example for
artifacts that are typically published to Maven Central, it currently
doesn't seem to be the convention to use any other purl type: the CycloneDX
Maven plugin pretty much hard-codes the 'maven' type (
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FCycloneDX%2Fcyclonedx-maven-plugin%2Fblob%2Fmaster%2Fsrc%2Fmain%2Fjava%2Forg%2Fcyclonedx%2Fmaven%2FDefaultModelConverter.java%23L147&data=05%7C02%7Cjan.von.loewenstein%40sap.com%7C7c65d1d7e6434f1ac5bb08dc6b6c81fd%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638503360979642858%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=7enw%2FbIYob1koLI8BvvdGpZzUuZQqnZVd8g8gg7%2FgPM%3D&reserved=0).
Should we then not have an 'apache'/'asf' type at all? Or only for
artifacts that cannot be described using any other type? Or for all
artifacts, making an 'equivalences database' a mandatory part of any
vulnerability scanner?


Kind regards,

Arnout

On Mon, Apr 15, 2024 at 2:20 PM von Loewenstein, Jan
 wrote:

> Hi all,
>
> I recently started a discussion about pURLs as package identifier on the
> Tomcat mailing list and it was brought up, that this might be a broader
> topic to be discussed here.
>
> Best regards
> Jan
>
> From: Thomas Hoffmann (Speed4Trade GmbH)
> 
> Date: Monday, 15. April 2024 at 13:14
> To: Tomcat Users List 
> Subject: AW: Package URLs for Apache Tomcat distributions
> [You don't often get email from thomas.hoffm...@speed4trade.com.invalid.
> Learn why this is important at
> https://aka.ms/LearnAboutSenderIdentification ]
>
> > On 11/04/2024 16:52, von Loewenstein, Jan wrote:
> > > Hi folks,
> > >
> > > I am part of the Paketo community, and we are providing Cloud Native
> > Buildpacks to create container images with – amongst other technologies –
> > Apache Tomcat and Apache TomEE as application runtimes.
> > >
> > > One of the features of Cloud Native Buildpacks is that images come with
> > Software-Bill-of-Material. When installing Apache Tomcat, we issue the
> > following CPE and pURL to the SBOM:
> > >
> > >1.  cpe:2.3:a:apache:tomcat:10.1.20:*:*:*:*:*:*:*
> > >2.  pkg:generic/apache-tomcat@10.1.20
> > >

Re: SPNEGO GSSCaller {UNKNOWN} No Delegated Creds

[Tom Delaney]

Thanks for the reply Michael,

I'm trying to achieve retrieving delegated credentials. I'm confused by the
debug output because I'm being told that authentication succeeded but no
indication of why I'm not receiving delegated credentials other than there
are none.I have looked over the delegation rules for the service account
and SPN multiple times. When you mentioned "S4U is tried, but not
configured for that account. Totally fine" What does that mean? Is there a
specific place on Tomcat or Windows I need to look for this?

What I'm expecting to see outputted "Delegated Creds have pname=
tdela...@subdomain.domain.com sname=krbtgt/SUBDOMAIN.DOMAIN.COM
authtime=null starttime={date/timestamp} endtime={date/timestamp}"

P.S
I see in my ktpass command I made a typo and meant to put SA_EX_VAISSO
instead of "SA_EX_SSO"

On Fri, May 3, 2024 at 8:26 AM Michael Osipov  wrote:

> On 2024/05/02 19:20:59 Tom Delaney wrote:
> > Hi All,
> >
> > Sorry for the duplicate requests. The first one was accidentally flagged
> > for Google's new Confidential Mode which happened to be flagged.
> > I have a red hat 9.2 server hosting a web application on a single
> instance
> > of Apache Tomcat. This instance is behind an apache HTTP server on
> version
> > 2.4.57.The application is hosted on Tomcat 9.0.54.
> >
> > Domain: subdomain.domain.com
> > Site: devexample.domain.com
> >
> > URL hit: https://example.subdomain.domain.com/webclient/
> > exclient.jsp
> >
> > *I keep getting this in the Tomcat Logs when accessing the application:*
> > *>>> Constrained deleg from GSSCaller{UNKNOWN}*
>
> You should first try to describe what you are trying to achieve and not
> what the debug output is. The debug message comes from:
> https://github.com/openjdk/jdk8u-dev/blob/6b53212ef78ad50f9eede829c5ff87cadcdb434b/jdk/src/share/classes/sun/security/jgss/krb5/Krb5Context.java#L540
> The message is obviously caused by this call:
> https://github.com/openjdk/jdk8u-dev/blob/6b53212ef78ad50f9eede829c5ff87cadcdb434b/jdk/src/share/classes/sun/security/jgss/krb5/Krb5Context.java#L254-L263
>
> S4U is tried, but not configured for that account. Totally fine.
>
> BTW: The filter you use isn't from us.
>
> M
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: FileUpload class not working with Tomcat 10.1

[Mark Foley]

On 4/23/24 18:44, Chuck Caldarale wrote:


   uploadfile






   uploadfile
   /schDistImportResults.jsp


The first servlet is named “uploadfile”.


On Apr 23, 2024, at 12:42, Mark Foley  wrote:

Now I need to add another program to the system that does file uploads. I
created another  definition in WEB-INF/web.xml following the original:


   uploadfile






   uploadfile
   /1099R-Etrans.jsp


This second servlet is also named “uploadfile”.


That didn't work so well.  Now, any and all programs using the fileupload
function launches this 2nd program 1099R-Etrans.jsp.  It appears that this
second  definition replaces the first.

You gave them the same names, so the second one wins...

What magic were you expecting to differentiate between the two?

   - Chuck

I can easily change the name of the second servlet, but how would the 
respective jsp programs (schDistImportResults.jsp, 1099R-Etrans.jsp) specify 
one or the other? The programs do:

String contentType = request.getContentType();

if (contentType.startsWith("multipart/form-data;"))
{
    Part fileUpload = request.getPart("taxResults");  // for 
schDistImportResults.jsp

// or
    Part fileUpload = request.getPart("vendor1099-MISC"); // for 
1099R-Etrans.jsp


    InputStream inFile = fileUpload.getInputStream();
 :
}

That's it. There is nothing in the program that specifies a servlet 
name. My initial servlet definition (for schDistImportResults.jsp) was 
based on the XML suggestion from Christopher Schultz back in November, 
2023. Since only the one jsp program was involved, there was no 
discussion of how to specify more than one program in web.xml.


So, I can (and will) give the servlets different names in web.xml, but 
how does the jsp program select the one for its use?


Thanks --Mark