Decoder for log messages???

Decoder for log messages???

[Dean Anderson]

I removed and reinstalled httpd, and got a bunch of these messages.  
I'm guessing that dm-0 refers to a devicemapper device (which on my
system doesn't seem to actually be in use, so I'm left wondering what
the heck...perhaps a shared device number)  I had to disable selinux
because I couldn't figure out how to fix the problem within a couple
minutes and needed to put the server back online.  

I think some directory was searched, but have no idea exactly what
directory. It caused httpd to terminate:

messages:Oct 26 21:35:03 mallard kernel: audit(1193448902.933:56): avc:  
denied  { search } for  pid=
11594 comm="httpd" name="sparc" dev=dm-0 ino=15699715 
scontext=root:system_r:httpd_t:s0 tcontext=system_u:object_r:src_t:s0 tclass=dir

So can anyone decode this to a full pathname?

Can you decode it in 6 months with only a filesystem dump? Because by
then one no longer has the file-to-inode-number association and has also
lost the device mapper mappings.


Comment: A log file entry may be reviewed long after the entry was made
and after the system that made the entry was destroyed. The destruction
of said system may be the reason for reviewing the logs. Since inode
numbers change across filesystem restoration, the inode number isn't a
permanent identifier. Device numbers and names are also dynamic.  So,
once this filesystem is destroyed, the log information is useless.  
This is a crack into selinux; the attacker merely has to tamper with a
file, and anticipating the log entry, compensates by destroying the
filesystem (after a backup).  The log entry is then useless.  The admin
knows some file was tampered with, but not which file.  The admin
probably has to use the backup because they can't dump months of work
and they don't have time to examine each file in a filesystem.


Comment: Putting a device basename and inode number in a log message
does not uniquely identify the file.  Nor is this helpful.  However, if
you think that full file names are too long to log (a questionable
assumption, but I won't question it now), then one must still uniquely
identify the file some other way.  That requires the FULL device path
name, and the inode number. (but as above, that isn't permanent 
identifier)


Comment: This problem is in the same nature of problem that backup
software often has; they also never seem to fully anticipate the
situation of a failure of some sort and what needs to be recovered to
make the backup system work well enough to perform a restore.  This
makes those systems fragile, and tedious during a failure when such
systems are needed most.  Likewise, SELinux was very fragile in this
case, because it was impossible or tediously difficult to find the cause
of the problem from the log entry.  But we have logs to keep track of
history and to identify problems.  Security is generally not improved by
obscurity. Obscure and ambiguous messages are harmful in every way
possible. Forensic evidence is also harmed.  When there is a security
problem, the problem needs to be made plain and permanently,
unambiguously described.

		--Dean


-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Decoder for log messages???

[Stephen Smalley]

On Sat, 2007-10-27 at 00:17 -0400, Dean Anderson wrote:
> I removed and reinstalled httpd, and got a bunch of these messages.  
> I'm guessing that dm-0 refers to a devicemapper device (which on my
> system doesn't seem to actually be in use, so I'm left wondering what
> the heck...perhaps a shared device number)

device mapper is used by the logical volume manager.
dmsetup ls?
cat /sys/block/dm-0/dev?

>   I had to disable selinux
> because I couldn't figure out how to fix the problem within a couple
> minutes and needed to put the server back online.

Hmm...well, there's always the option of using audit2allow, although it
is best to understand what you are allowing.

> I think some directory was searched, but have no idea exactly what
> directory. It caused httpd to terminate:
> 
> messages:Oct 26 21:35:03 mallard kernel: audit(1193448902.933:56): avc:  
> denied  { search } for  pid=
> 11594 comm="httpd" name="sparc" dev=dm-0 ino=15699715 
> scontext=root:system_r:httpd_t:s0 tcontext=system_u:object_r:src_t:s0 tclass=dir

So httpd tried to search a directory named "sparc" (with that device and
inode identifiers), and that directory was labeled "src_t", which
suggests that it might be under /usr/src somewhere.

> So can anyone decode this to a full pathname?

Not a full pathname, no.

We don't have enough information at the point where we do our permission
checks to reconstruct a pathname, and such a pathname will always be
process-local and not guaranteed to be meaningful, stable, or the actual
path by which the file was accessed.  The theory was that the audit
subsystem would solve that problem for us, and this was true for a
period of time until it was "optimized" to only collect that information
if at least one syscall audit filter was put into place.  So to get PATH
records, you have to put at least a dummy audit filter into place, ala:
	/sbin/auditctl -a exit,always -S chroot
or put the following at the end of /etc/audit/audit.rules to have it
take effect always when auditd is started:
-a exit,always -S chroot

> Can you decode it in 6 months with only a filesystem dump? Because by
> then one no longer has the file-to-inode-number association and has also
> lost the device mapper mappings.
> 
> 
> Comment: A log file entry may be reviewed long after the entry was made
> and after the system that made the entry was destroyed. The destruction
> of said system may be the reason for reviewing the logs. Since inode
> numbers change across filesystem restoration, the inode number isn't a
> permanent identifier. Device numbers and names are also dynamic.  So,
> once this filesystem is destroyed, the log information is useless.  
> This is a crack into selinux; the attacker merely has to tamper with a
> file, and anticipating the log entry, compensates by destroying the
> filesystem (after a backup).  The log entry is then useless.  The admin
> knows some file was tampered with, but not which file.  The admin
> probably has to use the backup because they can't dump months of work
> and they don't have time to examine each file in a filesystem.
> 
> 
> Comment: Putting a device basename and inode number in a log message
> does not uniquely identify the file.  Nor is this helpful.  However, if
> you think that full file names are too long to log (a questionable
> assumption, but I won't question it now), then one must still uniquely
> identify the file some other way.  That requires the FULL device path
> name, and the inode number. (but as above, that isn't permanent 
> identifier)
> 
> 
> Comment: This problem is in the same nature of problem that backup
> software often has; they also never seem to fully anticipate the
> situation of a failure of some sort and what needs to be recovered to
> make the backup system work well enough to perform a restore.  This
> makes those systems fragile, and tedious during a failure when such
> systems are needed most.  Likewise, SELinux was very fragile in this
> case, because it was impossible or tediously difficult to find the cause
> of the problem from the log entry.  But we have logs to keep track of
> history and to identify problems.  Security is generally not improved by
> obscurity. Obscure and ambiguous messages are harmful in every way
> possible. Forensic evidence is also harmed.  When there is a security
> problem, the problem needs to be made plain and permanently,
> unambiguously described.

We're not opposed to improving the information, but there are
constraints in terms of what information is available at the point of
the avc checks and what makes sense from the kernel's perspective.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Decoder for log messages???

[Russell Coker]

On Thursday 01 November 2007 01:26, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Sat, 2007-10-27 at 00:17 -0400, Dean Anderson wrote:
> > I removed and reinstalled httpd, and got a bunch of these messages.
> > I'm guessing that dm-0 refers to a devicemapper device (which on my
> > system doesn't seem to actually be in use, so I'm left wondering what
> > the heck...perhaps a shared device number)
>
> device mapper is used by the logical volume manager.
> dmsetup ls?
> cat /sys/block/dm-0/dev?

It's also used by cryptsetup and probably other things.

While LVM has support for persistent (across reboot) ID numbers I don't think 
that anyone uses them by default.  I believe that cryptsetup has no support 
for persistent IDs, and if you use LVM or cryptsetup on removable media then 
the possibility of having two devices want the same ID would make it 
difficult or impossible to use them.

So if you have a 6 month old log entry that referrs to dm-0 then it may be 
impossible to determine what it was from.

-- 
russell@coker.com.au
http://etbe.coker.com.au/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Decoder for log messages???

[Dean Anderson]

On Wed, 31 Oct 2007, Stephen Smalley wrote:
> 
> Not a full pathname, no.
> 
> We don't have enough information at the point where we do our permission
> checks to reconstruct a pathname, 

?? These checks are in open or exec. The full pathname should be 
available.

> and such a pathname will always be process-local and not guaranteed to
> be meaningful, stable, or the actual path by which the file was
> accessed.  

?? The filesystem is not process local, except perhaps /proc

> The theory was that the audit subsystem would solve that problem for
> us, and this was true for a period of time until it was "optimized" to
> only collect that information if at least one syscall audit filter was
> put into place.  So to get PATH records, you have to put at least a
> dummy audit filter into place, ala:
> 	/sbin/auditctl -a exit,always -S chroot 
> or put the following at the end of /etc/audit/audit.rules to have it
> take effect always when auditd is started: -a exit,always -S chroot

You can't get out what you don't put in.

		--Dean

> > Can you decode it in 6 months with only a filesystem dump? Because by
> > then one no longer has the file-to-inode-number association and has also
> > lost the device mapper mappings.
> > 
> > 
> > Comment: A log file entry may be reviewed long after the entry was made
> > and after the system that made the entry was destroyed. The destruction
> > of said system may be the reason for reviewing the logs. Since inode
> > numbers change across filesystem restoration, the inode number isn't a
> > permanent identifier. Device numbers and names are also dynamic.  So,
> > once this filesystem is destroyed, the log information is useless.  
> > This is a crack into selinux; the attacker merely has to tamper with a
> > file, and anticipating the log entry, compensates by destroying the
> > filesystem (after a backup).  The log entry is then useless.  The admin
> > knows some file was tampered with, but not which file.  The admin
> > probably has to use the backup because they can't dump months of work
> > and they don't have time to examine each file in a filesystem.
> > 
> > 
> > Comment: Putting a device basename and inode number in a log message
> > does not uniquely identify the file.  Nor is this helpful.  However, if
> > you think that full file names are too long to log (a questionable
> > assumption, but I won't question it now), then one must still uniquely
> > identify the file some other way.  That requires the FULL device path
> > name, and the inode number. (but as above, that isn't permanent 
> > identifier)
> > 
> > 
> > Comment: This problem is in the same nature of problem that backup
> > software often has; they also never seem to fully anticipate the
> > situation of a failure of some sort and what needs to be recovered to
> > make the backup system work well enough to perform a restore.  This
> > makes those systems fragile, and tedious during a failure when such
> > systems are needed most.  Likewise, SELinux was very fragile in this
> > case, because it was impossible or tediously difficult to find the cause
> > of the problem from the log entry.  But we have logs to keep track of
> > history and to identify problems.  Security is generally not improved by
> > obscurity. Obscure and ambiguous messages are harmful in every way
> > possible. Forensic evidence is also harmed.  When there is a security
> > problem, the problem needs to be made plain and permanently,
> > unambiguously described.
> 
> We're not opposed to improving the information, but there are
> constraints in terms of what information is available at the point of
> the avc checks and what makes sense from the kernel's perspective.
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Decoder for log messages???

[Steve Grubb]

On Monday 05 November 2007 04:28:29 pm Dean Anderson wrote:
> > We don't have enough information at the point where we do our permission
> > checks to reconstruct a pathname,
>
> ?? These checks are in open or exec. The full pathname should be
> available.

The audit system should pick up the name if you have at least one audit rule.

-Steve

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Decoder for log messages???

[Steve Grubb]

On Monday 05 November 2007 04:28:29 pm Dean Anderson wrote:
> > and such a pathname will always be process-local and not guaranteed to
> > be meaningful, stable, or the actual path by which the file was
> > accessed.  
>
> ?? The filesystem is not process local, except perhaps /proc

I think what he means is that if you have symlinks somewhere in the path or 
bind mount overlays, there could be several ways of identifying the same 
file. This is partly why the inode and filesystem is given. It helps identify 
exactly what is being accessed.

-Steve


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Decoder for log messages???

[Stephen Smalley]

On Mon, 2007-11-05 at 16:28 -0500, Dean Anderson wrote:
> On Wed, 31 Oct 2007, Stephen Smalley wrote:
> > 
> > Not a full pathname, no.
> > 
> > We don't have enough information at the point where we do our permission
> > checks to reconstruct a pathname, 
> 
> ?? These checks are in open or exec. The full pathname should be 
> available.

Not where we do the check, no.  The audit system though can collect the
component names as the lookup occurs, and emit the name at syscall exit.

> > and such a pathname will always be process-local and not guaranteed to
> > be meaningful, stable, or the actual path by which the file was
> > accessed.  
> 
> ?? The filesystem is not process local, except perhaps /proc

The view that a process has of the filesystem can be tailored on a
per-process basis in Linux; a given pathname is only meaningful relative
to a particular namespace.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

What can selinux do that "audit" by itself cant do ?

[Hasan Rezaul-CHR010]

Hi All,

Had a thought pop up in my head, and was just cusrious...

Lets say I am using SELinux in my Linux product to monitor the
filesystem and generate avc deny events in audit.log, whenever my strict
selinux policy is violated... And I am running in Permissive mode (so
NOT actively preventing anything, just reporting...).

Is there any reason why I cant simply write a bunch of rules in
audit.rules  to accomplish the same objective ?

Possibly a dumb question, so apologize in advance, but other than Policy
Enforcement and Prevention in the 'Enforcing' mode (which I cant use in
my product for various reasons), what else is SELinux buying me, that I
cant get by using just audit ?

I am sure there must be significant benefits of SELinux, but can someone
help me understand some of the benefits. 

And also perhaps some of the SELinux functionalities are desirable, but
cannot be accomplished by just audit. Can you tell me what those may be?
If there is an article or URL that provides more depth, please feel free
to share that as well.

Thanks as always for your help.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: What can selinux do that "audit" by itself cant do ?

[Steve Grubb]

Hello,

On Tuesday, November 30, 2010 07:17:30 pm Hasan Rezaul-CHR010 wrote:
> Lets say I am using SELinux in my Linux product to monitor the
> filesystem and generate avc deny events in audit.log, whenever my strict
> selinux policy is violated... And I am running in Permissive mode (so
> NOT actively preventing anything, just reporting...).
> 
> Is there any reason why I cant simply write a bunch of rules in
> audit.rules  to accomplish the same objective ?

I think that you want to use the right tool for the right job. The audit system is 
designed to monitor system activity. SE Linux is a MAC subsystem. There are 
requirements that MAC events are auditable, which seems to be what you have been using 
in place of just the audit system.

 It should be known that if you turn SE Linux off, you won't get the same events in the 
audit logs. This is because SE Linux can have policy written that does not like some 
interactions that are "legal" from a DAC perspective. The only way to know if you are 
missing anything important is to run with SE Linux disabled and see if the audit rules 
captures everything you expect.


> Possibly a dumb question, so apologize in advance, but other than Policy
> Enforcement and Prevention in the 'Enforcing' mode (which I cant use in
> my product for various reasons), what else is SELinux buying me, that I
> cant get by using just audit ?

SE Linux has helped debug many software problems like leaked file descriptors or shared 
memory that is executable. The audit system won't be able to catch those since it was 
never designed to concern itself with information flow control. It was designed to 
monitor resource access. Nearly the same, but different. For example, the audit system 
would assume that if a child process inheritted and used a descriptor from a parent 
process, then it must be OK. SE Linux because it worries about information flow control 
would be more suspicious and report a process attempting to access a resource that it 
was not known to previously have.

 
> I am sure there must be significant benefits of SELinux, but can someone
> help me understand some of the benefits.

Audit should be used for auditing, SE Linux should be used for access control. They 
are orthogonal.


> And also perhaps some of the SELinux functionalities are desirable, but
> cannot be accomplished by just audit. Can you tell me what those may be?
> If there is an article or URL that provides more depth, please feel free
> to share that as well.

-Steve

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: What can selinux do that "audit" by itself cant do ?

[Hasan Rezaul-CHR010]

Thank You soo much Steve for your answers  :-)

R.H.
 

-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com] 
Sent: Wednesday, December 01, 2010 7:45 AM
To: Hasan Rezaul-CHR010
Cc: Stephen Smalley; selinux@tycho.nsa.gov
Subject: Re: What can selinux do that "audit" by itself cant do ?

Hello,

On Tuesday, November 30, 2010 07:17:30 pm Hasan Rezaul-CHR010 wrote:
> Lets say I am using SELinux in my Linux product to monitor the 
> filesystem and generate avc deny events in audit.log, whenever my 
> strict selinux policy is violated... And I am running in Permissive 
> mode (so NOT actively preventing anything, just reporting...).
> 
> Is there any reason why I cant simply write a bunch of rules in 
> audit.rules  to accomplish the same objective ?

I think that you want to use the right tool for the right job. The audit
system is designed to monitor system activity. SE Linux is a MAC
subsystem. There are requirements that MAC events are auditable, which
seems to be what you have been using in place of just the audit system.

 It should be known that if you turn SE Linux off, you won't get the
same events in the audit logs. This is because SE Linux can have policy
written that does not like some interactions that are "legal" from a DAC
perspective. The only way to know if you are missing anything important
is to run with SE Linux disabled and see if the audit rules captures
everything you expect.


> Possibly a dumb question, so apologize in advance, but other than 
> Policy Enforcement and Prevention in the 'Enforcing' mode (which I 
> cant use in my product for various reasons), what else is SELinux 
> buying me, that I cant get by using just audit ?

SE Linux has helped debug many software problems like leaked file
descriptors or shared memory that is executable. The audit system won't
be able to catch those since it was never designed to concern itself
with information flow control. It was designed to monitor resource
access. Nearly the same, but different. For example, the audit system
would assume that if a child process inheritted and used a descriptor
from a parent process, then it must be OK. SE Linux because it worries
about information flow control would be more suspicious and report a
process attempting to access a resource that it was not known to
previously have.

 
> I am sure there must be significant benefits of SELinux, but can 
> someone help me understand some of the benefits.

Audit should be used for auditing, SE Linux should be used for access
control. They are orthogonal.


> And also perhaps some of the SELinux functionalities are desirable,
but
> cannot be accomplished by just audit. Can you tell me what those may
be?
> If there is an article or URL that provides more depth, please feel
free
> to share that as well.

-Steve


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.