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

[Chris Friedt]

Hmm... I understand what you're saying about verifying the distributor
SSL keys, etc. , and that will be taken care of by distributing the file
from our website. 

I suppose that if the installer does a proper chmod / chown of the jar
and the binary it's kindof pointless to worry about someone maliciously
modifying them, because that will ultimately boil down to be responsible
by security in the operating system itself. The argument about how to
protect a file is pretty cyclic in that respect.

> > 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).

I apologize for that thoughtless comment about Mac users - I realize
you have some knowlege about the Terminal - after all you're on this
list! Most of the Mac users that we will support here (I'm only speaking
about staff / faculty) are part of the Fashion / Image Arts departments.
I think my generalization was correct in that respect because they are
_mostly_ not very *nix savvy, and would _probably_ not have any idea how
to use a terminal. The whole point of what I was doing was to make this
as easy as possible for people who can mainly conceptualize 'point and
click', and there are plenty of those here.

Thanks for the suggestions though ;-)

~/Chris


>>> jaaaarel-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org 11/24/05 1:34:23 pm >>>
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
--
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