Bad file access on the rise

[Stephen John Smoogen]

On 7 June 2013 10:21, Lennart Poettering <mzerqung at 0pointer.de> wrote:

> On Fri, 07.06.13 12:09, Steve Grubb (sgrubb at redhat.com) wrote:
>
> > > > > POSIX shared memory doesn't define any useful scheme for automatic
> > > > > removing of shared memory segments from /dev/shm after use. Hence,
> in
> > > > > order to make sure that left-over segments don't fill up /dev/shm
> > > > > forever PA will try to GC dead segments from /dev/shm on each
> > > > > start-up. For that it iterates through /dev/shm/pulse-shm*, tries
> to
> > > > > read the PID that is stored in there.
> > > >
> > > > Maybe the uid can be encoded in the name so that wrong uid's are
> > > > skipped?
> > >
> > > But why?
> >
> > So that you are not filling up the audit logs. There are people that
> have to
> > use these audit rules and we need a normally operating system to produce
> as
> > few false positives as possible.
>
> Maybe the audit system should be fixed to not trip up by this?
>
>
The audit system is doing what it is supposed to do. Report that a file is
being tried to be opened with no permissions to do so. That is pretty much
the business rule required to be audited. Exceptions to that rule go up a
long chain of command and usually take various signoffs to make sure that
you aren't trying to get around the system somewhere. This kind of thing
affects everyone who has to deal with auditing in one form or another (PCI,
various .gov, various health agencies etc). They get a rule which is
written as simple as possible and then the audit system is to find all
attempts against that simple rule. And then someone or some group at the
site has to go through each attempt and figure out if the problem is a
legitimate one, a hacker, etc. When they find out it is a legitimate one,
the process is the following:

1) Open a ticket with the vendor that they have a problem.
2) Open a ticket up the chain of command to have an exception allowed.
[Ticket 1 usually takes months to years but is usually faster than ticket
2.]

Then most large sites go through their chain of command tickets and find
out which ones cost the most and then put those vendors on notice that
their products are not meeting expectations and that they want either a
larger discount to cover the hidden costs or they will be finding another
vendor.




-- 
Stephen J Smoogen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130607/3c85df87/attachment.html>