uid<-->username question

uid<-->username question

[LC Bruzenak]

All,

I was thinking about a scheme to retrieve usernames from UIDs on
different machines. I was going to push the passwd file from a
participating audit client up to the server. Then I'll store it uniquely
according to its IP address (e.g. /var/etc/passwd.192.168.10.10). 

Then, I'd change the parse code which looks up the username from
getpwuid().

In the case where the host was localhost, I'd still use the getpwuid()
call. In the case where it is another host, I'd use fgetpwent() on the
particular host's passwd file.
I see that the name-value cache will have to be modified or maybe a
UID/hostname/username triplet cache will need to be used instead for
UIDs.

On the sender, I was thinking that I already have an excellent
audit-based file watch in place. Ideally, on a /etc/passwd addition, I'd
like to fire a rule to automatically send the modified hosts file up to
the collector machine.

Any thoughts on this? I realize in most systems an LDAP server is
adequate for federated logins and no code changes or schemes are
necessary. I do not have this and likely never will given my
environment. I also have to ensure that the participating systems do not
reuse old UIDs or remove expired ones from their password file.

I also realize this code change may be of little use to the general
community, but if I do this and others have similar restrictions I'd be
happy to share what I do.

Thx in advance,
LCB.

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

Re: uid<-->username question

[LC Bruzenak]

On Thu, 2009-03-05 at 10:08 -0600, LC Bruzenak wrote:
> All,
> 
> I was thinking about a scheme to retrieve usernames from UIDs on
> different machines. I was going to push the passwd file from a
> participating audit client up to the server. Then I'll store it uniquely
> according to its IP address (e.g. /var/etc/passwd.192.168.10.10). 
...
Forgot to add - one alternative is to replace the UIDs in the events
with the usernames, but I thought that one might be a bigger impact to
the code base.

LCB.
-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

Re: uid<-->username question

[John Dennis]

LC Bruzenak wrote:
> All,
>
> I was thinking about a scheme to retrieve usernames from UIDs on
> different machines. I was going to push the passwd file from a
> participating audit client up to the server. Then I'll store it uniquely
> according to its IP address (e.g. /var/etc/passwd.192.168.10.10). 
>
> Then, I'd change the parse code which looks up the username from
> getpwuid().
>
> In the case where the host was localhost, I'd still use the getpwuid()
> call. In the case where it is another host, I'd use fgetpwent() on the
> particular host's passwd file.
> I see that the name-value cache will have to be modified or maybe a
> UID/hostname/username triplet cache will need to be used instead for
> UIDs.
>
> On the sender, I was thinking that I already have an excellent
> audit-based file watch in place. Ideally, on a /etc/passwd addition, I'd
> like to fire a rule to automatically send the modified hosts file up to
> the collector machine.
>
> Any thoughts on this? I realize in most systems an LDAP server is
> adequate for federated logins and no code changes or schemes are
> necessary. I do not have this and likely never will given my
> environment. I also have to ensure that the participating systems do not
> reuse old UIDs or remove expired ones from their password file.
>
> I also realize this code change may be of little use to the general
> community, but if I do this and others have similar restrictions I'd be
> happy to share what I do.
>
> Thx in advance,
> LCB.
>
>   
I think this approach is problematic. First of all the set of uid's from 
a given machine is ephemeral. The contents of the passwd file needs to 
be matched to a time interval matching the log data. Secondly, the 
passwd file is sensitive data, you probably do not want to be shipping 
that over the network and storing it without a lot of safeguards. 
Thirdly, it's not just uid's that are have local context (machine local 
and time local), gid's,  ip-addr -> hostname mapping, kernel version 
dependent data encodings, etc. are just some of the data you won't be 
able to interpret correctly at some point in the future on some 
disassociated remote machine.

Because there are many problems with taking the audit log in it's 
current form and storing it remotely for later analysis in IPA we are 
not going to collect the audit log in it's default form. Instead we're 
going to resolve (e.g. interpret using auparse terminology) all the data 
on the local machine *before* we collect and store it. We plan on doing 
this by writing a audispd plugin which resolves all the ambiguous local 
data as it's generated (and hence before it's ever collected). This 
solves both the locality of time and locality of host issues and 
tremendously simplifies post-mortum analysis because the log data will 
have been stripped of ambiguities and replaced with data that can simply 
be read and used with no extra processing.


-- 
John Dennis <jdennis@redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/

Re: uid<-->username question

[LC Bruzenak]

On Thu, 2009-03-05 at 11:48 -0500, John Dennis wrote:
> LC Bruzenak wrote:
...
> > environment. I also have to ensure that the participating systems do not
> > reuse old UIDs or remove expired ones from their password file.
> >

> I think this approach is problematic. First of all the set of uid's from 
> a given machine is ephemeral. The contents of the passwd file needs to 
> be matched to a time interval matching the log data. Secondly, the 
> passwd file is sensitive data, you probably do not want to be shipping 
> that over the network and storing it without a lot of safeguards. 
> Thirdly, it's not just uid's that are have local context (machine local 
> and time local), gid's,  ip-addr -> hostname mapping, kernel version 
> dependent data encodings, etc. are just some of the data you won't be 
> able to interpret correctly at some point in the future on some 
> disassociated remote machine.

Good points John; thanks. Most of the things which apply to "normal"
use-cases illustrated by what you describe don't apply to me, and so for
the most people I realize what I need is silly.

My UIDs are by fiat not ephemeral. GIDs are not either. If a user's role
changes they get a new username with the associated GID.
IP<-->hostname mapping isn't via DHCP and won't be  in the foreseeable
future. Not sure about "kernel version dependent data encodings" but I
guess you mean future kernel audit event structure. That one is larger
then me anyway I think.

As I said, good points and I also agree that it is problematic. However,
given the timeline I'm working on I might have to assume some inadequacy
in order to meet schedule.

> 
> Because there are many problems with taking the audit log in it's 
> current form and storing it remotely for later analysis in IPA we are 
> not going to collect the audit log in it's default form. Instead we're 
> going to resolve (e.g. interpret using auparse terminology) all the data 
> on the local machine *before* we collect and store it. We plan on doing 
> this by writing a audispd plugin which resolves all the ambiguous local 
> data as it's generated (and hence before it's ever collected). This 
> solves both the locality of time and locality of host issues and 
> tremendously simplifies post-mortum analysis because the log data will 
> have been stripped of ambiguities and replaced with data that can simply 
> be read and used with no extra processing.
> 
> 

I think this is an excellent approach and when ready for action I'll
look to incorporate. So you are normalizing at the source. This is
essentially what I figured was a bigger effort than my suggested
kludge. 

Thanks for the info; I really appreciate it!
LCB.

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com