saddr value in connect()

saddr value in connect()

[lists_todd]

I have a question about the SOCKADDR token in a SYSCALL record (syscall 42 -- connect())

Most of my records begin with one of the two values:
	saddr=0200
	saddr=0100

Followed by the port & IPv4 address or the file path.

QUESTION 1: The file path appears to be NULL terminated. Is this correct?

QUESTION 2: There is often additional characters after the 00 termination (and IP address). Is this just garbage that should be ignored?

QUESTION 3: Sometimes the first byte in a file path is 00 termination (e.g., saddr=0100002F…). Does this mean the string is empty and the content following it is garbage? Or is there a bug that accidentally prepends the 00 to the front of the saddr sequence?

Here is an example:

————————
type=SYSCALL msg=audit(1397089029.264:7407): arch=c000003e syscall=42 success=yes exit=0 a0=3 a1=7fff3a7fdf70 a2=16 a3=7fff3a7fdd20 items=0 ppid=805 pid=1064 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="initctl" exe="/sbin/initctl" key=(null)

type=SOCKADDR msg=audit(1397089029.264:7407): saddr=0100002F636F6D2F7562756E74752F75707374617274
————————

If I assume the first 00 is a bug, the string decodes to

	/com/ubuntu/upstart

Thanks,

Todd

PS. uname -r gives 3.13.0-24-generic (though, I think I collected these logs before the last software update)

Re: saddr value in connect()

[Steve Grubb]

On Mon, 05 May 2014 15:11:56 -0700
lists_todd@mac.com wrote:

> I have a question about the SOCKADDR token in a SYSCALL record
> (syscall 42 -- connect())
> 
> Most of my records begin with one of the two values:
> 	saddr=0200
> 	saddr=0100
> 
> Followed by the port & IPv4 address or the file path.

saddr is a hex encoded blob that is a struct sockaddr.

> QUESTION 1: The file path appears to be NULL terminated. Is this
> correct?

Its a socket address structure. It may or may not be null terminated
depending on the socket type.
 
> QUESTION 2: There is often additional characters after the 00
> termination (and IP address). Is this just garbage that should be
> ignored?

Its other fields in struct sockaddr.

> QUESTION 3: Sometimes the first byte in a file path is 00 termination
> (e.g., saddr=0100002F…). Does this mean the string is empty and the
> content following it is garbage? Or is there a bug that accidentally
> prepends the 00 to the front of the saddr sequence?

That would be an abstract af_unix socket.

-Steve

> Here is an example:
> 
> ————————
> type=SYSCALL msg=audit(1397089029.264:7407): arch=c000003e syscall=42
> success=yes exit=0 a0=3 a1=7fff3a7fdf70 a2=16 a3=7fff3a7fdd20 items=0
> ppid=805 pid=1064 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
> egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="initctl"
> exe="/sbin/initctl" key=(null)
> 
> type=SOCKADDR msg=audit(1397089029.264:7407):
> saddr=0100002F636F6D2F7562756E74752F75707374617274 ————————
> 
> If I assume the first 00 is a bug, the string decodes to
> 
> 	/com/ubuntu/upstart
> 
> Thanks,
> 
> Todd
> 
> PS. uname -r gives 3.13.0-24-generic (though, I think I collected
> these logs before the last software update)
> 
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit


--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: saddr value in connect()

[lists_todd]

[-- Attachment #1.1: Type: text/plain, Size: 742 bytes --]


On May 5, 2014, at 3:26 PM, Steve Grubb <sgrubb@redhat.com> wrote:

> saddr is a hex encoded blob that is a struct sockaddr.

I’m writing my own parsing code to add Linux analysis to my Mac-based BSM audit analysis tools, so I might be asking some “out of left field” questions from time to time. I’ve been working my way through decoding things like the sockaddr hex blob.


>> …
> 
> Its a socket address structure. It may or may not be null terminated
> depending on the socket type.
> 
>> ...
> 
> Its other fields in struct sockaddr.
> 
>> ...
> 
> That would be an abstract af_unix socket.


With that info I did a little more digging and found a lot of this information in

	$ man 7 unix

Thanks!

Todd


[-- Attachment #1.2: Type: text/html, Size: 2105 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: saddr value in connect()

[Steve Grubb]

lists_todd@mac.com wrote:
> I’m writing my own parsing code to add Linux analysis to my Mac-based
> BSM audit analysis tools, so I might be asking some “out of left
> field” questions from time to time. I’ve been working my way through
> decoding things like the sockaddr hex blob.

Out of curiosity, why don't you use auparse to write your BSM
reformatter? I used it to reformat audit events into IDMEF events. Its
used for zos log aggregator. We will likely be needing to make changes
soon and it would insulate you from those kinds of issues.

-Steve

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: saddr value in connect()

[lists_todd]

Sorry for the long delay in getting back.

On May 6, 2014, at 10:55 AM, Steve Grubb <sgrubb@redhat.com> wrote:

> Out of curiosity, why don't you use auparse to write your BSM
> reformatter?

(1) I hadn’t run across the code repository until after you had mentioned it (I’ve only been actively looking at Linux auditing for a few weeks), and (2) I am still very much in the learning phase, trying to figure out what is in the data, what type of configuration I would like, etc. 


I will take a look at auparse soon. I am particularly interested in performance. My first parsing effort is *way* too slow. I use C++ regex a lot, and that seems to be a problem.

If anyone is interested is seeing Linux audit data (along with BSM) on a Mac, I posted a blog entry along with a little video:

	Analyzing Linux Audit Data
	http://www.toddheberlein.com/blog/2014/5/13/analyzing-linux-audit-data

> We will likely be needing to make changes soon and it would insulate you from those kinds of issues.

Can I ask what type of changes and what is motivating the changes?


Thanks,

Todd

Re: saddr value in connect()

[Steve Grubb]

On Thu, 15 May 2014 09:20:47 -0700
lists_todd@mac.com wrote:
> > Out of curiosity, why don't you use auparse to write your BSM
> > reformatter?
> 
> (1) I hadn’t run across the code repository until after you had
> mentioned it (I’ve only been actively looking at Linux auditing for a
> few weeks), and (2) I am still very much in the learning phase,
> trying to figure out what is in the data, what type of configuration
> I would like, etc. 
> 
> 
> I will take a look at auparse soon. I am particularly interested in
> performance. My first parsing effort is *way* too slow. I use C++
> regex a lot, and that seems to be a problem.

In general, I wouldn't think you need use regex all the time. Auparse
organizes things into events, record, fields, and accessor function at
each level. Its really easy to walk through events in a couple lines of
code and ask for translations without having to figure out how to
decode or where it comes from. Auparse will also add metadata in the
near future so that you can see how each field belongs to time,
location, subject, object, action, or result.


> If anyone is interested is seeing Linux audit data (along with BSM)
> on a Mac, I posted a blog entry along with a little video:
> 
> 	Analyzing Linux Audit Data
> 	http://www.toddheberlein.com/blog/2014/5/13/analyzing-linux-audit-data
> 
> > We will likely be needing to make changes soon and it would
> > insulate you from those kinds of issues.
> 
> Can I ask what type of changes and what is motivating the changes?

Typically evolving common criteria requirements or other security
needs. The main point is really that you can whip together a translator
in an afternoon with having to be concerned with the lowest level
details.

-Steve

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit