Thursday Oct 18, 2007

More Security for Unsigned Applets

I don't like signed applets.

Thus I'm thinking about adding a new clause into the java.policy file, something like this:

grant codebase "http://a.org/b.jar" md5sum 1234... {
    permission ...
}

If I know the developer of the applet quite well, or I've asked some experts to study the applet carefully, I may grant more permissions to the applet (Remember? I always believe that even an unsigned applet can be written to access "sensitive" resources, since the user can always allow it). However, I cannot guarantee that an applet would not be upgraded, or a bad guy hijack my DNS server and put his own applet there with the same URL. A checksum should be quite useful here.

Some problems: Even an unmodified jar, if hijacked, can also bring security problems. For example, an applet can always send info back to its origin, then this hijacked applet will send the precious info I innocently allow it to read on my hard disk back to the bad guy.

But, currently even a signed applet can be hijacked this way also. If some hijacks the Google website (very common in China these days), I will get an HTTPS hostname not matched warning when I browse to GMail. However, if Google releases its mail client as a signed Java applet but its residing page is hijacked by someone, will I be able to detect it? The verification of the code is only happening on the client side, and the private key (the only thing not hijacked) is not involved. Of course, the applet will still use HTTPS to connect with the server, so there still has a chance. But, before the connection, is there any bad things it can do?

Seems not, if the applet is written in a nice style, if it does not connect back to its origin in a plain socket...

OK, I'll think more on this.

Monday Jun 18, 2007

krb5.conf

It seems there's no place defining the exact grammar of krb5.conf. This is my attempt:

There are 5 semantic elements in a krb5.conf file:
  1. section head: "[" identifier "]"
  2. simple key-value: key "=" value
  3. complicated key: key "="
  4. complicated value start: "{"
  5. complicated value end: "}"
Normally, identifier and key should be alphanumeric plus a few symbols like ".", "-", "_"; value can be any series of characters with no newline inside and neither starts with "{" nor ends with "}". Each element can have zero or more blanks (spaces or horizontal tabs) between the tokens, before the first token, or after the last token.

A krb5.conf data includes an ordered series of these elements with the following constraints:
  1. The first element (if there exists one) must be a section head.
  2. Each appearance of a complicated value end must match an existing unmatched complicated value start. If there are multiple unmatched complicated value start elements, it matches the last (nearest) one.
  3. The section head must appear at a position where no complicated value start is un-matched.
  4. A complicated value start must follow a complicated key, a complicated key must be followed by a complicated value start.
  5. At the end of the data, no complicated value start is un-matched.
A krb5.conf file consists of multiple lines, in which each line can be:
  1. a comment line, starting with the character "#" or ";"
  2. an empty line, consisting of zero or more blanks
  3. an element
  4. a glue of multiple elements, which means several consequent elements are packed into one line
There can be two different form of a krb5.conf:
  1. Distinguished form: The only allowed glue is between complicated key and complicated value start. In fact, in the distinguished form, these 2 elements must always be glued.
  2. Basic form: The complicated value start element can be either glued to the element before it, or the one after it. The complicated value end can be glued to the element before it. Glued elements can be glued again by matching the "ends". No glue is mandatory.

Other ideas:

  1. Weird characters ("=", "[", "]", "{", "}", and other invisibles) inside key or identifier or value must be escaped with "\\" using the standard C style. I hate quotes, and I hate those "you needn't escape it here coz I can recognize it" cases.
  2. Any unescaped "#" inside a line starts an until-the-eol comment (";" doesn't)

Tuesday Jan 24, 2006

spyware

andrew points me to a website that tries to define what spyware is and how an app should act nicely when it still wants to collect user information. if such a specification is ready, it will be a good chance to implement it in a java library, say, the PoliteFeedback library. this will be very useful for software makers that develop non-networking-specific applications.

inside there, the communication codes use doPrivilege to call socket methods so the caller won't need a SocketPermission. on the other hand, a new permission type -- PoliteFeedbackPermission -- is defined, that must be granted in order to send the feedback to the vendor. the permission will have some arguments to precisely define how the feedback can be performed.

so now the software publisher can request this permission in their installer. users will be happy to see that the only network communication the app will perform is polite feedback. the user can further config the feedback type (for example, data must be shown to the user before sent) or completely deny any feedback.

auto-update can also be included in the library, which means the same consortium should also define what a polite auto-update should behave.

Monday Oct 10, 2005

why do i love unsigned applets (much) more?

i love unsigned applets and java web start programs, because they are innocent. that's the way of java -- when people don't claim how innocent they are, they are truely innocent. they won't do anything harmful to your system. if they do want to access your file system or other any sensitive part, they will let you control all the thing, they are safe.

on the other hand, signed applets are always evil, that's the attitude of trust-me-wholly-or-not. (which reminds me of the windows ActiveX controls.) if you accept the signer's credit, then the applet can just do anything on your system. the current JRE honestly shows a dialog box indicating this. every time when i need to press the "i accept" button, i pray that it really be a nice player, and the programmer behind it has not intentionally or un-intentionally added any evil codes inside. i know there are ways to deal with this with usePolicy or so, but they need client-side config. it's acceptable inside an enterprise, but surely useless for we out in the public and want to protect us from the unknown sites.



so, why it cannot act at some point in between? inside the signed jar, somewhere in the meta directory, we can just put a file app.policy that we can specify a list of Permissions that we want to explicitly grant to the codes inside. then, instead of "this application will be run without the security restrictions normally provided by Java", it can show something like "this application will have access to part of your file system and the network". a button labeled "more" will show the permissions.toFriendlyString() in more details. once this file is placed in the jar, the plugin security manager will enforce the permissions as described. this way, i'll be more comfortable running them.

will this be a new feature in dolphin?

About

This blog has a comments managing system that requires me to approve each comment manually. Please do not re-post and I will reply it (if I have an answer) when I get pinged.

Search

Top Tags
Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today