root shell auditing

[Mars Gobetti]

In an effort to comply with iso 27001, Webtrust and other security certifications I need to audit root shell usage on many linux servers: every bash command entered in the shell ,with timestamps, and possibly logging to a remote server.
Which is the best (enterprise class) way to do that?

Currently in our environment administrators get root shell access using sudo -i. Do I need to change this?
I've seen around sudosh (wich do the job locally), then Enterprise Audit Shell, but it seems to me this projects are not active any more.
Will Free IPA be an answer?

Thank you,

Mars Gobetti

[Tim Brown-2]

On Monday 28 July 2008 14:34:12 Mars Gobetti wrote:

> In an effort to comply with iso 27001, Webtrust and other security
> certifications I need to audit root shell usage on many linux servers:
> every bash command entered in the shell ,with timestamps, and possibly
> logging to a remote server. Which is the best (enterprise class) way to do
> that?
>
> Currently in our environment administrators get root shell access using
> sudo -i. Do I need to change this? I've seen around sudosh (wich do the job
> locally), then Enterprise Audit Shell, but it seems to me this projects are
> not active any more. Will Free IPA be an answer?
>
> Thank you,
>
> Mars Gobetti

I've deployed eTrust AC on large Unix estates for this purpose.  Like sudo but
rules are enforced at the kernel level.  Auditing can be applied to many
object classes including files, services, privileges etc.   Combine it with
eTrust Audit and you can aggregate logs and perform correlation etc.  It is
however quite expensive.

Cheers,
Tim
--
Tim Brown
<mailto:tmb@...>

[Huzeyfe Onal]

Hi,

you can use auditd (http://linux.die.net/man/8/auditd) for Linux systems.


Huzeyfe ONAL
huzeyfe@...
http://www.lifeoverip.net

Ag guvenligi listesine uye oldunuz mu?
http://netsec.lifeoverip.net
---


On Mon, Jul 28, 2008 at 4:34 PM, Mars Gobetti <erresei6@...> wrote:

>
> In an effort to comply with iso 27001, Webtrust and other security certifications I need to audit root shell usage on many linux servers: every bash command entered in the shell ,with timestamps, and possibly logging to a remote server.
> Which is the best (enterprise class) way to do that?
>
> Currently in our environment administrators get root shell access using sudo -i. Do I need to change this?
> I've seen around sudosh (wich do the job locally), then Enterprise Audit Shell, but it seems to me this projects are not active any more.
> Will Free IPA be an answer?
>
> Thank you,
>
> Mars Gobetti
>

[TJ Easter]

Mars,
       Not sure if it's an exact fit, but I put together a small patch
against bash 3.x a while back for someone that logs all commands to
syslog.   It hooks the commands as they're being logged into bash's
history buffer, so a (remote) syslog can capture commands in real
time.

      I don't recall what all it logged.  I believe UID, $PWD, and
command.  Timestamp came from syslog.

     Let me know if you're interested, I'll dig around for the .diff
and send it to you.


Regards,
TJ Easter

On Mon, Jul 28, 2008 at 8:34 AM, Mars Gobetti <erresei6@...> wrote:

> In an effort to comply with iso 27001, Webtrust and other security certifications I need to audit root shell usage on many linux servers: every bash command entered in the shell ,with timestamps, and possibly logging to a remote server.
> Which is the best (enterprise class) way to do that?
>
> Currently in our environment administrators get root shell access using sudo -i. Do I need to change this?
> I've seen around sudosh (wich do the job locally), then Enterprise Audit Shell, but it seems to me this projects are not active any more.
> Will Free IPA be an answer?
>
> Thank you,
>
> Mars Gobetti
>
>

--
"Being a humanist means trying to behave decently without expectation
of rewards or punishment after you are dead." -- Kurt Vonnegut, 1922 -
2007
http://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x5EB6E92FE2340DEF

[Diego Lacerda]

Hi, Mars,

I think that you could use Linux Process Accounting to audit
everything that you need in a shell environment.

Regards,
Diego Lacerda.

On 7/28/08, Mars Gobetti <erresei6@...> wrote:

> In an effort to comply with iso 27001, Webtrust and other security certifications I need to audit root shell usage on many linux servers: every bash command entered in the shell ,with timestamps, and possibly logging to a remote server.
> Which is the best (enterprise class) way to do that?
>
> Currently in our environment administrators get root shell access using sudo -i. Do I need to change this?
> I've seen around sudosh (wich do the job locally), then Enterprise Audit Shell, but it seems to me this projects are not active any more.
> Will Free IPA be an answer?
>
> Thank you,
>
> Mars Gobetti
>
>

--
Diego Evaristo de Lacerda (diegolacerda@...)
Analista de Projetos
LPIC Level III & Redhat Certified Engineer & Cisco Certified Network Associates

URL: conectado.motime.com

[Dan Hanman]

Hey TJ,

I think this would be a great and very useful tool. Could you post is
somewhere where we/I can also download?

Regards

Dan

-----Original Message-----
From: listbounce@... [mailto:listbounce@...]
On Behalf Of TJ Easter
Sent: 29 July 2008 11:01
To: Mars Gobetti
Cc: focus-linux
Subject: Re: root shell auditing

Mars,
       Not sure if it's an exact fit, but I put together a small patch
against bash 3.x a while back for someone that logs all commands to
syslog.   It hooks the commands as they're being logged into bash's
history buffer, so a (remote) syslog can capture commands in real
time.

      I don't recall what all it logged.  I believe UID, $PWD, and
command.  Timestamp came from syslog.

     Let me know if you're interested, I'll dig around for the .diff
and send it to you.


Regards,
TJ Easter

On Mon, Jul 28, 2008 at 8:34 AM, Mars Gobetti <erresei6@...>
wrote:
> In an effort to comply with iso 27001, Webtrust and other security
certifications I need to audit root shell usage on many linux servers:
every bash command entered in the shell ,with timestamps, and possibly
logging to a remote server.
> Which is the best (enterprise class) way to do that?
>
> Currently in our environment administrators get root shell access
using sudo -i. Do I need to change this?
> I've seen around sudosh (wich do the job locally), then Enterprise
Audit Shell, but it seems to me this projects are not active any more.
> Will Free IPA be an answer?
>
> Thank you,
>
> Mars Gobetti
>
>



--
"Being a humanist means trying to behave decently without expectation
of rewards or punishment after you are dead." -- Kurt Vonnegut, 1922 -
2007
http://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x5EB6E92FE2340DEF


No virus found in this incoming message.
Checked by AVG - http://www.avg.com 
Version: 8.0.138 / Virus Database: 270.5.6/1579 - Release Date:
29/07/2008 06:43

[THORNTON Simon]

Hi Marc,

In addition to auditd you could also use the "script" command as this records not only what was typed but what the response was as
well. By adding this as a login shell or as the last line of the /etc/profile script you can trigger it when someone logs in.
Everything after that, including su/sudo etc will be logged.

See the man page on script for how to save the log and timing info to other locations.

Rgds,

Simon

-----Original Message-----
From: listbounce@... [mailto:listbounce@...] On Behalf Of Mars Gobetti
Sent: Monday, July 28, 2008 15:34
To: focus-linux
Subject: root shell auditing

In an effort to comply with iso 27001, Webtrust and other security certifications I need to audit root shell usage on many linux
servers: every bash command entered in the shell ,with timestamps, and possibly logging to a remote server.
Which is the best (enterprise class) way to do that?

Currently in our environment administrators get root shell access using sudo -i. Do I need to change this?
I've seen around sudosh (wich do the job locally), then Enterprise Audit Shell, but it seems to me this projects are not active any
more.
Will Free IPA be an answer?

Thank you,

Mars Gobetti

[JW-19]

On Monday 28 July 2008 08:34:12 Mars Gobetti wrote:

> In an effort to comply with iso 27001, Webtrust and other security
> certifications I need to audit root shell usage on many linux servers:
> every bash command entered in the shell ,with timestamps, and possibly
> logging to a remote server. Which is the best (enterprise class) way to do
> that?
>
> Currently in our environment administrators get root shell access using
> sudo -i. Do I need to change this? I've seen around sudosh (wich do the job
> locally), then Enterprise Audit Shell, but it seems to me this projects are
> not active any more. Will Free IPA be an answer?

Consider trying snoopy, it logs all commands that are executed by all users
and daemons - not just directly in the shell, but if you run a script from
the shell and the script calls other commands - they will all be logged. I
find that it helps with debugging sometimes, too.

A few distros package it.

http://freshmeat.net/projects/snoopy_logger/

It does not log bash internals (for example, "alias" or "source") but it will
log any commands that are run by them.

        JW

--

----------------------
System Administrator - Cedar Creek Software
http://www.cedarcreeksoftware.com

[Hari Sekhon]

TJ Easter wrote:

> Mars,
>        Not sure if it's an exact fit, but I put together a small patch
> against bash 3.x a while back for someone that logs all commands to
> syslog.   It hooks the commands as they're being logged into bash's
> history buffer, so a (remote) syslog can capture commands in real
> time.
>
>       I don't recall what all it logged.  I believe UID, $PWD, and
> command.  Timestamp came from syslog.
>
>      Let me know if you're interested, I'll dig around for the .diff
> and send it to you.
>  

Awesome, so I should just spawn zsh or tcsh ... to work around this? ;-)

-h

--
Hari Sekhon

[Hari Sekhon]

Diego Lacerda wrote:
> Hi, Mars,
>
> I think that you could use Linux Process Accounting to audit
> everything that you need in a shell environment.
>  
I've tried this, it lacks some detail if I remember correctly it doesn't
log params as it was designed for process accounting, not security
auditing, which could mean missing a lot as sometimes it's the
parameters that make all the difference between a normal and a dangerous
action.

So far for me, snoopy comes closest.

-h

--
Hari Sekhon

[David Bruce-4]

TJ,

I'd be interested in this, as well. I have a new junior admin, and if
anything were to break, I'd be able to trace it back.

Thanks,

David Bruce

-----Original Message-----
From: listbounce@... [mailto:listbounce@...]
On Behalf Of Dan Hanman
Sent: Wednesday, July 30, 2008 3:28 AM
To: TJ Easter; Mars Gobetti
Cc: focus-linux
Subject: RE: root shell auditing

Hey TJ,

I think this would be a great and very useful tool. Could you post is
somewhere where we/I can also download?

Regards

Dan

-----Original Message-----
From: listbounce@... [mailto:listbounce@...]
On Behalf Of TJ Easter
Sent: 29 July 2008 11:01
To: Mars Gobetti
Cc: focus-linux
Subject: Re: root shell auditing

Mars,
       Not sure if it's an exact fit, but I put together a small patch
against bash 3.x a while back for someone that logs all commands to
syslog.   It hooks the commands as they're being logged into bash's
history buffer, so a (remote) syslog can capture commands in real
time.

      I don't recall what all it logged.  I believe UID, $PWD, and
command.  Timestamp came from syslog.

     Let me know if you're interested, I'll dig around for the .diff
and send it to you.


Regards,
TJ Easter

On Mon, Jul 28, 2008 at 8:34 AM, Mars Gobetti <erresei6@...>
wrote:
> In an effort to comply with iso 27001, Webtrust and other security
certifications I need to audit root shell usage on many linux servers:
every bash command entered in the shell ,with timestamps, and possibly
logging to a remote server.
> Which is the best (enterprise class) way to do that?
>
> Currently in our environment administrators get root shell access
using sudo -i. Do I need to change this?
> I've seen around sudosh (wich do the job locally), then Enterprise
Audit Shell, but it seems to me this projects are not active any more.
> Will Free IPA be an answer?
>
> Thank you,
>
> Mars Gobetti
>
>



--
"Being a humanist means trying to behave decently without expectation
of rewards or punishment after you are dead." -- Kurt Vonnegut, 1922 -
2007
http://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x5EB6E92FE2340DEF


No virus found in this incoming message.
Checked by AVG - http://www.avg.com 
Version: 8.0.138 / Virus Database: 270.5.6/1579 - Release Date:
29/07/2008 06:43

[Philip Turner]

On 31 Jul 2008 at 10:24, Hari Sekhon wrote:

> Diego Lacerda wrote:
> > Hi, Mars,
> >
> > I think that you could use Linux Process Accounting to audit
> > everything that you need in a shell environment.
> >  
> I've tried this, it lacks some detail if I remember correctly it doesn't
> log params as it was designed for process accounting, not security
> auditing, which could mean missing a lot as sometimes it's the
> parameters that make all the difference between a normal and a dangerous
> action.
>

I'll just play play devil's advocate for a moment here, and
suggest that as you log more and more detail you increase the
risk that you'll include sensitive information that shouldn't be
revealed to whoever reviews the security logs. Eventually you've
just replaced the need to trust the admins with the need to
trust the security reviewers.  

(I'm not saying you've reached this point yet, just that it's
something to think about each time you up the level of detail.)  


> So far for me, snoopy comes closest.
>
> -h
>
> --
> Hari Sekhon
>


--
Phil Turner

Computers have no common sense - _we_users_ need to supply that.

[Marian Rudzynski]

Hari Sekhon wrote:

> Diego Lacerda wrote:
>> Hi, Mars,
>>
>> I think that you could use Linux Process Accounting to audit
>> everything that you need in a shell environment.
>>  
> I've tried this, it lacks some detail if I remember correctly it
> doesn't log params as it was designed for process accounting, not
> security auditing, which could mean missing a lot as sometimes it's
> the parameters that make all the difference between a normal and a
> dangerous action.
>
> So far for me, snoopy comes closest.
>
> -h
>

The Kernel accounting/audit might actually be the only real thing here
though.

I'm currently in need of a thourough accouting/auditing setup myself and
I haven't managed to find anything that does the job as needed (e.g. secure)

Snoopy hasn't been maintained for a long time and segfaults on x86_64,
"linuxbsm" (an attempt to create a Linux Basic Security Module) hasn't
been maintained since 2001 either and bash patches just won't suffice.

So if anyone knows of any other reasonably secure and practicable way to
do these things, recommend it. My guess is kernel accounting/audit is
the way to go however.

[Hari Sekhon]

Marian Rudzynski wrote:

> Hari Sekhon wrote:
>> Diego Lacerda wrote:
>>> Hi, Mars,
>>>
>>> I think that you could use Linux Process Accounting to audit
>>> everything that you need in a shell environment.
>>>  
>> I've tried this, it lacks some detail if I remember correctly it
>> doesn't log params as it was designed for process accounting, not
>> security auditing, which could mean missing a lot as sometimes it's
>> the parameters that make all the difference between a normal and a
>> dangerous action.
>>
>> So far for me, snoopy comes closest.
>>
>> -h
>>
> The Kernel accounting/audit might actually be the only real thing here
> though.
>
> I'm currently in need of a thourough accouting/auditing setup myself
> and I haven't managed to find anything that does the job as needed
> (e.g. secure)
>
> Snoopy hasn't been maintained for a long time and segfaults on x86_64,
> "linuxbsm" (an attempt to create a Linux Basic Security Module) hasn't
> been maintained since 2001 either and bash patches just won't suffice.
>
> So if anyone knows of any other reasonably secure and practicable way
> to do these things, recommend it. My guess is kernel accounting/audit
> is the way to go however.
>

Ok but that also won't do what you want. I could tell you that cat was
run but it wouldn't tell you what the args where to know if someone used
it to overwrite or append to some file critical to the security of your
system (or just accidentally catted over the wrong file and lost the
contents...)

I'm also watching this space very closely for an open source champion to
spring up for this auditing challenge.


Perhaps you could force everybody to use sudo for every command that
requires root privs and have automated alerting if anyone does a direct
root login or a sudo su or an sudo (/usr)?/bin/shell_of_your_choice type
thing...

sudo does log properly and if all commands go through it, then you win.
This way all root commands would either be logged or you'd be alerted to
someone intentionally circumventing the logging by getting a full root
shell.


So far nothing I've seen in open source has gotten the whole picture of
external progs, shell built-ins, and cli args to be completely covered.

There are a couple of proprietary solutions I've seen that solve this
problem by forcing you to connect to your servers through their box so
they can record every keystroke and session output, but I think they are
far from cheap.

The idea of entire session capture is a pretty good one though as it
makes it very difficult to circumvent by doing things like spawning a
different shell to get around the logging bash patch...

-h

--
Hari Sekhon

[Hari Sekhon]

Philip Turner wrote:

> On 31 Jul 2008 at 10:24, Hari Sekhon wrote:
>  
>> Diego Lacerda wrote:
>>    
>>> Hi, Mars,
>>>
>>> I think that you could use Linux Process Accounting to audit
>>> everything that you need in a shell environment.
>>>  
>>>      
>> I've tried this, it lacks some detail if I remember correctly it doesn't
>> log params as it was designed for process accounting, not security
>> auditing, which could mean missing a lot as sometimes it's the
>> parameters that make all the difference between a normal and a dangerous
>> action.
>>
>>    
>
> I'll just play play devil's advocate for a moment here, and
> suggest that as you log more and more detail you increase the
> risk that you'll include sensitive information that shouldn't be
> revealed to whoever reviews the security logs. Eventually you've
> just replaced the need to trust the admins with the need to
> trust the security reviewers.  
>
> (I'm not saying you've reached this point yet, just that it's
> something to think about each time you up the level of detail.)  
>  

Anyone would think I'm an evil security guy or something... ;-)

Seriously though, you're making an assumption that it's just admins.
Developers use the command line too and often aren't anywhere near as
smart or industry educated as they think they are which is why sometimes
it's very handy if you can check on what they've done.

A good example was a guy we had who was supposed to be a very good
developer but got a command wrong and stopped a website from working. I
had his command in the logs and proved it was his fault. So much for
being so smart.. you'd think someone who was so good would know how to
use a simple command and not append "." and ".." as args which went
outside the directory he intended to. If you make a mistake once, ok
it's a typo, but he did the same thing the next day too so I had to tell
him to be more careful, which I could since I had proof it was his fault
(I had his cwd as well in this case to match against the relatives . and
..).

Moral of the story: logging and auditing are very important and make me
feel much better.

-h

--
Hari Sekhon

[Glynn Clements]

Hari Sekhon wrote:

> Perhaps you could force everybody to use sudo for every command that
> requires root privs and have automated alerting if anyone does a direct
> root login or a sudo su or an sudo (/usr)?/bin/shell_of_your_choice type
> thing...
>
> sudo does log properly and if all commands go through it, then you win.
> This way all root commands would either be logged or you'd be alerted to
> someone intentionally circumventing the logging by getting a full root
> shell.

Looking for specific commands won't work. There are just too many
"indirect" ways to execute a command.

Even if you log everything which the user types and review those logs
thoroughly, there are still ways to slip things past the reviewer,
especially if the user is allowed to use interactive programs (vi,
less, etc), or whose behaviour can be influenced by the contents of
files (which may have changed or been removed by the time that you
review the logs).

The only mechanism which won't miss anything is logging at the syscall
level, i.e. auditctl/auditd. Even that won't tell you everything
that's happening (logging read() and write() would overwhelm the
logs), but it should be enough to detect suspicious activity, and it
cannot be bypassed in the way that logging user input or commands can.

--
Glynn Clements <glynn@...>

[Hari Sekhon]

Glynn Clements wrote:

> Hari Sekhon wrote:
>
>  
>> Perhaps you could force everybody to use sudo for every command that
>> requires root privs and have automated alerting if anyone does a direct
>> root login or a sudo su or an sudo (/usr)?/bin/shell_of_your_choice type
>> thing...
>>
>> sudo does log properly and if all commands go through it, then you win.
>> This way all root commands would either be logged or you'd be alerted to
>> someone intentionally circumventing the logging by getting a full root
>> shell.
>>    
>
> Looking for specific commands won't work. There are just too many
> "indirect" ways to execute a command.
>
> Even if you log everything which the user types and review those logs
> thoroughly, there are still ways to slip things past the reviewer,
> especially if the user is allowed to use interactive programs (vi,
> less, etc), or whose behaviour can be influenced by the contents of
> files (which may have changed or been removed by the time that you
> review the logs).
>
> The only mechanism which won't miss anything is logging at the syscall
> level, i.e. auditctl/auditd. Even that won't tell you everything
> that's happening (logging read() and write() would overwhelm the
> logs), but it should be enough to detect suspicious activity, and it
> cannot be bypassed in the way that logging user input or commands can.
>  

True true.

So back to the other solution I mentioned which is auditing every
keystroke, input and output of every session.

But alas this is a proprietary solution.

I want an open source version of this so much...

-h

--
Hari Sekhon

[Hari Sekhon]

cybergod wrote:
> You can implement a simple system by using /usr/bin/script utility and
> pipe it a fifo on a NFS share for example. You need to establish a
> policy of course because there's an easy way to go around it. For more
> info and example read "man script".
>
> Hope this helps,
>
> Konstantin Ivanov
Yes I know this one. The problems with all of these little hacks is that
they are easily circumventable.

GrSecurity's Exec logging is something I'm investigating right now...
I've used it's chdir logging on a chrooted server of mine and it's quite
thorough.

-h

--
Hari Sekhon

[security-41]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
You can implement a simple system by using /usr/bin/script utility and
pipe it a fifo on a NFS share for example. You need to establish a
policy of course because there's an easy way to go around it. For more
info and example read "man script".

Hope this helps,
Konstantin Ivanov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
iEYEARECAAYFAkiZ6UUACgkQB3wRB5KUBPm7ngCgmcJBxNerBnxIA4DNsLYnvaWn
ofUAoIHIesDT9IAJKHQimkUkofUksSCP
=nJTI
-----END PGP SIGNATURE-----



Hari Sekhon wrote:

> > Philip Turner wrote:
>  
>> >> On 31 Jul 2008 at 10:24, Hari Sekhon wrote:
>> >>
>>    
>>> >>> Diego Lacerda wrote:
>>> >>>  
>>>      
>>>> >>>> Hi, Mars,
>>>> >>>>
>>>> >>>> I think that you could use Linux Process Accounting to audit
>>>> >>>> everything that you need in a shell environment.
>>>> >>>>        
>>>>        
>>> >>> I've tried this, it lacks some detail if I remember correctly it
>>>      

doesn't log params as it was designed for process accounting, not
security auditing, which could mean missing a lot as sometimes it's the
parameters that make all the difference between a normal and a dangerous
action.

>>> >>>
>>> >>>    
>>>      
>> >>
>> >> I'll just play play devil's advocate for a moment here, and suggest
>>    
that as you log more and more detail you increase the risk that you'll
include sensitive information that shouldn't be revealed to whoever
reviews the security logs. Eventually you've just replaced the need to
trust the admins with the need to trust the security reviewers.

>> >> (I'm not saying you've reached this point yet, just that it's
>>    
something to think about each time you up the level of detail.)  

> > Anyone would think I'm an evil security guy or something...  ;-)
> >
> > Seriously though, you're making an assumption that it's just admins.
>  
Developers use the command line too and often aren't anywhere near as
smart or industry educated as they think they are which is why sometimes
it's very handy if you can check on what they've done.

> >
> > A good example was a guy we had who was supposed to be a very good
>  
developer but got a command wrong and stopped a website from working. I
had his command in the logs and proved it was his fault. So much for
being so smart.. you'd think someone who was so good would know how to
use a simple command and not append "." and ".." as args which went
outside the directory he intended to. If you make a mistake once, ok
it's a typo, but he did the same thing the next day too so I had to tell
him to be more careful, which I could since I had proof it was his fault
(I had his cwd as well in this case to match against the relatives . and ..

> > Moral of the story: logging and auditing are very important and make me
>  
feel much better.

> >
> > -h
> >
>  

[Christian Lete-2]

Hi,

Maybe sudosh can suit your needs.

http://sourceforge.net/projects/sudosh/

Cheers,

Christian

-----Mensaje original-----
De: listbounce@... [mailto:listbounce@...] En
nombre de Hari Sekhon
Enviado el: Miércoles, 06 de Agosto de 2008 03:16 p.m.
Para: cybergod
CC: p.turner@...; focus-linux
Asunto: Re: root shell auditing

cybergod wrote:
> You can implement a simple system by using /usr/bin/script utility and
> pipe it a fifo on a NFS share for example. You need to establish a
> policy of course because there's an easy way to go around it. For more
> info and example read "man script".
>
> Hope this helps,
>
> Konstantin Ivanov
Yes I know this one. The problems with all of these little hacks is that
they are easily circumventable.

GrSecurity's Exec logging is something I'm investigating right now...
I've used it's chdir logging on a chrooted server of mine and it's quite
thorough.

-h

--
Hari Sekhon