First, a bit of background to explain what's going on: Files in OS X can have two quite different kinds of permission settings applied to them: POSIX and ACLs.
Files always (well, almost always) have POSIX permissions applied, consisting of an owner, group, and others (with some combination of read, write, and execute for each of those). There is no way to control inheritance of POSIX permissions: new items are always owned by whatever user created them, the group assignment is inherited from the folder they're in, and the access is determined by the umask (which is pretty much always: owner gets full access, group and others read only + execute for folders). So POSIX permissions won't work for what you're trying to do.
Files can also have an access control list (ACL) applied. This is a list of access control entries (ACEs), each of which applies to a user or group, specifies types of access (in great detail), whether they're being allowed or denied, and whether the ACE should also be copied to items created inside the folder. That last bit is the part that makes this useful for you; you need to create an ACE on the folder that specifies the group you want, the types of access you want, and full inheritance.
chmod on OS X can manipulate ACEs with the +a, -a, etc permissions options. If I understand what you want, you'd use this (with your group name and folder path substituted) to create the ACE:
chmod +a "group:examplegroup allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit" /path/to/folder
Note that the inheritance is not "live", i.e. it doesn't apply to items created before you assigned the ACE, and it doesn't apply to items created somewhere else and then moved into the folder. You can apply it to existing contents by using -R (chmod -R +a ...). I don't know of a way (except Apple's server admin tools) to force inheritance to items moved into the folder.
I don't know either, but here's how to find out more
In cases of entirely unknown binaries, strings(1) is often helpful in getting a hint about what the file might be
strings /tmp/ics29586 | less
Have a look through the output and see if it's anything familiar.
Failing that, find out which launchd job it is being launched from:
launchctl list|awk '{id=$3; print "### " id; system("launchctl list " id)}'|awk '/^###/ {id=$2} /.*ics29586.*/ {print id}'
This should output one or more job tags in the form of (for example) com.apple.scrod (and a few errors, which you can ignore).
Once you have the job tag(s), get the launchd config for a job by running:
launchctl list com.apple.scrod # insert your tag instead
This (and the tag itself, which often contains an internet domain name in reverse notation) should give you some more information about what this process is. Feel free to post it here if you need further help.
Update: Forgot to mention this, but since it's a jar file, you can copy it somewhere and unzip it (jar files are really just zip files) and have a look at what sort of Java classes are in there.
Best Answer
From terminal, you'll want to start with
system_profilerAlso, much more data is available from
ioregbut you'll need to parse the output (which can arrive as XML if you prefer) to get things like actual bus and clock frequency of each core.