Archive for the ‘JEDI Windows Security Code Lib’ Category

Setting file security with JWSCL

Sometimes it is necessary to change the security settings of a file or folder for getting or denying write access. With JWSCL this task is made very easy. However there are some pitfalls to avoid. The following code will also be available in the example section of the source code. The application gets a file [...]

The current download version of JWSCL (rev 316) contains a memory leak in the method EnumerateSession of class TJwTerminalServer in unit JwsclTerminal. The reason is a string variable in the local thread storage (LTS) (maintained by threadvar) that is not freed automatically by Delphi. The new version uses a widestring instead of string which fixes [...]

The JEDI API Library project (JWA) has been successfully revived from a sleep status to an active project with lots of ambitions. Some recent achievements are the new include model of JWA, the release of JWSCL (the Security Library) and of course the “birth” of this blog.

Where is the RELEASE conditional?

JWSCL uses (rarely) the DEBUG compiler condition definition like in “What is the internal variable TJwSecurityID.fDbgData for?“. However there is no “RELEASE” directive. Why? The reason is simple: There is no need for. If you don’t define DEBUG, JWSCL will be compiled without any debug codes. If you need a release condition, you can simply [...]

Sometimes it is necessary to retrieve a user’s token or act as a user who is logged on. By default a service uses the SYSTEM token and this leads to a security problem. If a service solves tasks send by another low privileges process (client), the client can do things it shouldn’t do. For this [...]

I found this very interesting article about exceptions. You should read “Ten Things (or more) You Might Not Know About Exception Handling in Delphi” (or get it from  Google Cache) and learn why exception inheritance ist important. The same reason applies to the exceptions of the JWSCL. EJwsclSecurityException is the main exception inherited from generic [...]

If you try to make your application more secure against external plugins (or better code) by impersonating a low privileged user and then call the plugin function, isn’t that wise. You could also do nothing which has the same effect. Malicious code can easily revert to the process token by calling the API RevertToSelf though. [...]

Whenever you impersonate a running thread and create a new thread while impersonating, your new thread will not get impersonated, too. The new thread will run without any thread token and thus a called function will use the process token instead. So you have to impersonate the new thread again. Ignoring that fact may lead [...]

This is the road map of JWA and JWSCL for the year 2008. Add and test Rudy Velthuis headers for Delphi to JWA (done but needs review) Implement COM interfaces and classes for JWSCL Implement new Winsta (Terminal Service) declarations for JWA and JWSCL Convert embedded source documentation to Doc-o-Matic (of course buy that nice [...]

Yes, we did LsaLogonUser

I was asked if we had implemented LsaLogonUser – the function from hell. Yes, we did. You can find it in the online documation @ JwsclLsa.TJwSecurityLsa.LsaLogonUser (Unit.Class.Method). LsaLogonUser and JwsclToken.TJwSecurityToken.CreateNewToken are not documented at the moment. However: These functions should only used for a really good reason. Otherwise the system security can be breached.

Paypal donation (EUR)

Archives

 

May 2012
M T W T F S S
« Oct    
 123456
78910111213
14151617181920
21222324252627
28293031