Hi,
I just updated to refpolicy-20090619 (late last week), and am
trying to eliminate the AVC denials from my Debian unstable box
(running in permissive mode). My policy-fu is a little rust, so I
thought I'd report the denials here -- I hope this is the right
place. I'll try and break up the reports into manageable chunks over
time.
These AVC denials are spit out during bootup, just after policy
load.
Jun 22 16:21:07 anzu kernel: type=1400 audit(1245705630.106:3): avc: denied { read write } for pid=1235 comm="hostname" name="console" dev=sdb2 ino=952166 scontext=system_u:system_r:hostname_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=chr_file
Jun 22 16:21:07 anzu kernel: type=1400 audit(1245705630.137:4): avc: denied { open } for pid=1235 comm="hostname" name="urandom" dev=sdb2 ino=952137 scontext=system_u:system_r:hostname_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=chr_file
The following seems to be caused by my .forward file, though I d
not see why; the mail is delivered to a filter program that ought to be
running as me, if the fetchmail policy is right.
type=AVC msg=audit(1245708192.070:377): avc: denied { append } for pid=8226 comm="hostname" path="/home/srivasta/var/log/mailerrors" dev=dm-4 ino=6094914 scontext=system_u:system_r:hostname_t:s0 tcontext=system_u:object_r:user_home_t:s0 tclass=file
Thanks for any help
manoj
--
Nobody can be as agreeable as an uninvited guest.
Manoj Srivastava <[email protected]> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
On Thu, 2009-06-25 at 13:32 -0500, Manoj Srivastava wrote:
> Hi,
>
> I just updated to refpolicy-20090619 (late last week), and am
> trying to eliminate the AVC denials from my Debian unstable box
> (running in permissive mode). My policy-fu is a little rust, so I
> thought I'd report the denials here -- I hope this is the right
> place. I'll try and break up the reports into manageable chunks over
> time.
>
> These AVC denials are spit out during bootup, just after policy
> load.
>
> Jun 22 16:21:07 anzu kernel: type=1400 audit(1245705630.106:3): avc: denied { read write } for pid=1235 comm="hostname" name="console" dev=sdb2 ino=952166 scontext=system_u:system_r:hostname_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=chr_file
> Jun 22 16:21:07 anzu kernel: type=1400 audit(1245705630.137:4): avc: denied { open } for pid=1235 comm="hostname" name="urandom" dev=sdb2 ino=952137 scontext=system_u:system_r:hostname_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=chr_file
Looks like mislabeled files. Are there any static device nodes under
the udev /dev?
> The following seems to be caused by my .forward file, though I d
> not see why; the mail is delivered to a filter program that ought to be
> running as me, if the fetchmail policy is right.
>
> type=AVC msg=audit(1245708192.070:377): avc: denied { append } for pid=8226 comm="hostname" path="/home/srivasta/var/log/mailerrors" dev=dm-4 ino=6094914 scontext=system_u:system_r:hostname_t:s0 tcontext=system_u:object_r:user_home_t:s0 tclass=file
Perhaps this is from a leaked fd (there is no open denial)?
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150
An embedded and charset-unspecified text was scrubbed...
Name: avc-urandom.txt
Url: http://oss.tresys.com/pipermail/refpolicy/attachments/20090701/5066a78a/attachment-0001.txt
On Wed, 2009-07-01 at 09:54 -0500, Manoj Srivastava wrote:
> On Thu, Jun 25 2009, Christopher J. PeBenito wrote:
>
> > On Thu, 2009-06-25 at 13:32 -0500, Manoj Srivastava wrote:
>
> > Looks like mislabeled files. Are there any static device nodes under
> > the udev /dev?
>
> Well, there were no static files, but there was an underlying
> /dev directory that was unlabeled, and the warnings were from before
> udev created the overlay mount. In any case, I used a liveCD to access,
> and label, the static /dev underlay, and the avc denials have been much
> mitigated.
>
> I updated the policy to the git version from the 29th, and I
> have been noticing a whole slew of avc denials (about 23 distinct
> entities) that were denied open/read access to /dev/urandom; the logs
> are attached. These were not just early boot; I continue to get ping
> and hostname denials periodically.
>
> If these attempts to read /dev/urandom are spurious, should
> there be dontaudit clauses to prevent these from filling up the log?
Does debian use SSP now? This is what I would expect if many programs,
if not all, are compiled with SSP. If so, use the global_ssp tunable.
> plain text document attachment (avc-urandom.txt), "avc denials for
> urandom"
> ----
> time->Mon Jun 29 13:44:46 2009
> type=SYSCALL msg=audit(1246301086.056:17): arch=c000003e syscall=2 success=yes exit=3 a0=7f7176904906 a1=0 a2=7f7176ae66f0 a3=22 items=0 ppid=2221 pid=2234 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty1 ses=4294967295 comm="loadkeys" exe="/bin/loadkeys" subj=system_u:system_r:loadkeys_t:s0 key=(null)
> type=AVC msg=audit(1246301086.056:17): avc: denied { open } for pid=2234 comm="loadkeys" name="urandom" dev=tmpfs ino=6857 scontext=system_u:system_r:loadkeys_t:s0 tcontext=system_u:object_r:urandom_device_t:s0 tclass=chr_file
> type=AVC msg=audit(1246301086.056:17): avc: denied { read } for pid=2234 comm="loadkeys" name="urandom" dev=tmpfs ino=6857 scontext=system_u:system_r:loadkeys_t:s0 tcontext=system_u:object_r:urandom_device_t:s0 tclass=chr_file
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150