java UI wrapper for 'smbpasswd' - change remote ADS password on Mac OS X

[Taavi Burns]

On 11/24/05, Chris Friedt <Chfriedt-0jnyayh6ARPqzrOJbVgLALDks+cytr/Z at public.gmane.org> wrote:
...
> I GUESS the Mac users could run the actual smbpasswd binary that I ship
> them - or even compile it themselves, or use fink, etc  - but then do
> most Mac users even know what the Terminal is ?

Considering that I bought my Mac _because_ it had Terminal (along with
a very pretty wrapper), I'd have to say that some do.  What percentage
is an entirely different matter.  That percentage probably also
changes in an academic environment, particularly a techncial one (as
compared to the general population).

> The funny thing about all of this is that Ryerson probably would have
> spent $1,500 on license fees / software to buy some commercial app for
> this extremely simple task.

Given the time you put into it (including the implicit time spent in
understanding the requirements), that's probably about how much you
could have charged. :)

> Aside from the obvious harm that could come if someone were to replace
> the smbpasswd binary after it's been installed on that machine, does
> anyone know of a good security measure?
>
> I'm thinking about md5-ing the actual smbpasswd binary that I ship, so
> that if it doesn't match the exact hash I could give a warning to the
> user and exit.

I'm no security guru, but adding an md5 hash to the .jar which checks
the supplied smbpasswd utility sounds like way more work than it's
worth.  Really, if someone wanted to subvert the process, they'd just
modify the .jar itself; why bother with the binary?

Short of signing the whole .jar (including smbpasswd) utility with
your private key and having students/staff verify the signing before
using the tool, I don't know of any relatively simple way to prevent a
trojan attack, e.g.:  Someone grabs your source code and modifies the
Java code to also send a copy to him/her, and then starts distributing
that version of the tool, claiming that it's yours.  About the only
other way I can think to provide everyone with a secure
password-change facility is to make it web-based with an authorized
SSL cert (or going through the hassle of getting everyone to accept
the cert the first time).

--
taa
/*eof*/
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml