FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora SELinux Support

 
 
LinkBack Thread Tools
 
Old 12-08-2009, 07:43 PM
Arthur Dent
 
Default Selinux & Fail2Ban

On Mon, 2009-12-07 at 23:51 +0100, Dominick Grift wrote:

> > > > > > > > [Snip]

> > > >
> > > > # matchpathcon /usr/bin/fail2ban-server
> > > > /usr/bin/fail2ban-server system_ubject_r:fail2ban_exec_t:s0
> > > >
> > > > Is that what you would expect to see?
> > >
> > > yes, now the question is, is the path labeled the way it should be:
> > >
> > > ls -alZ /usr/bin/fail2ban-server
> >
> > # ls -alZ /usr/bin/fail2ban-server
> > -rwxr-xr-x. root root unconfined_ubject_r:bin_t:s0 /usr/bin/fail2ban-server
> >
> > Hmmmm...
> >
> > # restorecon -v /usr/bin/fail2ban-server
> > restorecon reset /usr/bin/fail2ban-server context unconfined_ubject_r:bin_t:s0->system_ubject_r:fail2ban_exec_t:s0
> >
> > # ls -alZ /usr/bin/fail2ban-server
> > -rwxr-xr-x. root root system_ubject_r:fail2ban_exec_t:s0 /usr/bin/fail2ban-server
> >
> > Ahhh...
> >
> > Is that more like it?
>
> Yes that should get you atleast a little closer. I am wondering what else may be mislabeled on your system.
>
> maybe a relabel/fixfiles restore is in order...

Yes. Good advice.

As it happens there was a new selinux policy available today (using yum
update):
# rpm -q selinux-policy selinux-policy-targeted
selinux-policy-3.6.12-91.fc11.noarch
selinux-policy-targeted-3.6.12-91.fc11.noarch


I removed two of my local policies (log rotation and fail2ban) and put
selinux into permissive mode.

Having updated I did a "touch /.autorelabel; reboot"

Following your 7 point plan I believe I am now at stage 6?
{
1) I believe there is a type created for the process? (fail2ban_exec)
2) I believe there is a type for the executable file (fail2ban_exec)
3) declare the two types init_daemon_domain(). (Not sure about this)
4) The executable file is labelled with the type fail2ban_exec
5) I have started the service (in permissive mode).
}

I got 5 AVCs. 2 on startup and 3 when fail2ban actually hit on a rule.
(Copies of the AVCs below)

So - point 6: Using audit2allow I get this:

=================8<=============================== =============

module myfail2ban 11.2.1;

require {
type iptables_t;
type system_mail_t;
type fail2ban_t;
class unix_stream_socket { read write };
}

#============= iptables_t ==============
allow iptables_t fail2ban_t:unix_stream_socket { read write };

#============= system_mail_t ==============
allow system_mail_t fail2ban_t:unix_stream_socket { read write };

=================8<=============================== =============

So what do you think?

Am I on the right track?

Thanks again for all your help.

Mark


AVCs (I think a couple may be duplicates - I'm running in permissive
mode):

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1260298720.4:21): avc: denied { read write } for pid=1907 comm="iptables" path="socket:[16217]" dev=sockfs ino=16217 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket
node=troodos.org.uk type=SYSCALL msg=audit(1260298720.4:21): arch=40000003 syscall=11 success=yes exit=0 a0=8a1a250 a1=8a1a460 a2=8a19738 a3=8a1a460 items=0 ppid=1906 pid=1907 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="iptables" exe="/sbin/iptables" subj=system_u:system_r:iptables_t:s0 key=(null)

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1260298720.169:22): avc: denied { read write } for pid=1921 comm="sendmail" path="socket:[16217]" dev=sockfs ino=16217 scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket
node=troodos.org.uk type=SYSCALL msg=audit(1260298720.169:22): arch=40000003 syscall=11 success=yes exit=0 a0=85867d0 a1=8587798 a2=8587670 a3=8587798 items=0 ppid=1919 pid=1921 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=51 sgid=51 fsgid=51 tty=(none) ses=4294967295 comm="sendmail" exe="/usr/sbin/sendmail.sendmail" subj=system_u:system_r:system_mail_t:s0 key=(null)

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1260301404.622:121): avc: denied { read write } for pid=2799 comm="iptables" path="socket:[16217]" dev=sockfs ino=16217 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket
node=troodos.org.uk type=SYSCALL msg=audit(1260301404.622:121): arch=40000003 syscall=11 success=yes exit=0 a0=88b13e0 a1=88b1618 a2=88b06f8 a3=88b1618 items=0 ppid=2798 pid=2799 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="iptables" exe="/sbin/iptables" subj=system_u:system_r:iptables_t:s0 key=(null)

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1260301405.169:122): avc: denied { read write } for pid=2804 comm="iptables" path="socket:[16217]" dev=sockfs ino=16217 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket
node=troodos.org.uk type=SYSCALL msg=audit(1260301405.169:122): arch=40000003 syscall=11 success=yes exit=0 a0=96e3418 a1=96e3718 a2=96e2700 a3=96e3718 items=0 ppid=1901 pid=2804 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="iptables" exe="/sbin/iptables" subj=system_u:system_r:iptables_t:s0 key=(null)

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1260301405.212:123): avc: denied { read write } for pid=2811 comm="sendmail" path="socket:[16217]" dev=sockfs ino=16217 scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket
node=troodos.org.uk type=SYSCALL msg=audit(1260301405.212:123): arch=40000003 syscall=11 success=yes exit=0 a0=a119518 a1=a119a48 a2=a119750 a3=a119a48 items=0 ppid=2807 pid=2811 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=51 sgid=51 fsgid=51 tty=(none) ses=4294967295 comm="sendmail" exe="/usr/sbin/sendmail.sendmail" subj=system_u:system_r:system_mail_t:s0 key=(null)


--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 12-08-2009, 07:57 PM
Dominick Grift
 
Default Selinux & Fail2Ban

On Tue, Dec 08, 2009 at 08:43:32PM +0000, Arthur Dent wrote:
> On Mon, 2009-12-07 at 23:51 +0100, Dominick Grift wrote:
>
> > > > > > > > > [Snip]
>
> > > > >
> > > > > # matchpathcon /usr/bin/fail2ban-server
> > > > > /usr/bin/fail2ban-server system_ubject_r:fail2ban_exec_t:s0
> > > > >
> > > > > Is that what you would expect to see?
> > > >
> > > > yes, now the question is, is the path labeled the way it should be:
> > > >
> > > > ls -alZ /usr/bin/fail2ban-server
> > >
> > > # ls -alZ /usr/bin/fail2ban-server
> > > -rwxr-xr-x. root root unconfined_ubject_r:bin_t:s0 /usr/bin/fail2ban-server
> > >
> > > Hmmmm...
> > >
> > > # restorecon -v /usr/bin/fail2ban-server
> > > restorecon reset /usr/bin/fail2ban-server context unconfined_ubject_r:bin_t:s0->system_ubject_r:fail2ban_exec_t:s0
> > >
> > > # ls -alZ /usr/bin/fail2ban-server
> > > -rwxr-xr-x. root root system_ubject_r:fail2ban_exec_t:s0 /usr/bin/fail2ban-server
> > >
> > > Ahhh...
> > >
> > > Is that more like it?
> >
> > Yes that should get you atleast a little closer. I am wondering what else may be mislabeled on your system.
> >
> > maybe a relabel/fixfiles restore is in order...
>
> Yes. Good advice.
>
> As it happens there was a new selinux policy available today (using yum
> update):
> # rpm -q selinux-policy selinux-policy-targeted
> selinux-policy-3.6.12-91.fc11.noarch
> selinux-policy-targeted-3.6.12-91.fc11.noarch
>
>
> I removed two of my local policies (log rotation and fail2ban) and put
> selinux into permissive mode.
>
> Having updated I did a "touch /.autorelabel; reboot"
>
> Following your 7 point plan I believe I am now at stage 6?
> {
> 1) I believe there is a type created for the process? (fail2ban_exec)
> 2) I believe there is a type for the executable file (fail2ban_exec)
> 3) declare the two types init_daemon_domain(). (Not sure about this)
> 4) The executable file is labelled with the type fail2ban_exec
> 5) I have started the service (in permissive mode).
> }
>
> I got 5 AVCs. 2 on startup and 3 when fail2ban actually hit on a rule.
> (Copies of the AVCs below)
>
> So - point 6: Using audit2allow I get this:
>
> =================8<=============================== =============
>
> module myfail2ban 11.2.1;
>
> require {
> type iptables_t;
> type system_mail_t;
> type fail2ban_t;
> class unix_stream_socket { read write };
> }
>
> #============= iptables_t ==============
> allow iptables_t fail2ban_t:unix_stream_socket { read write };
>
> #============= system_mail_t ==============
> allow system_mail_t fail2ban_t:unix_stream_socket { read write };
>
> =================8<=============================== =============
>
> So what do you think?
>
> Am I on the right track?

Yes "allow system_mail_t fail2ban_t:unix_stream_socket { read write };", signals a leaked file descriptor on fail2ban. This issue is known. You can ignore those avc denials and/or silence them:

echo "policy_module(myfail2ban, 1.0.0)" > myfail2ban.te;
echo "optional_policy(`" >> myfail2ban.te;
echo "gen_require(`" >> myfail2ban.te;
echo "attribute domain;" >> myfail2ban.te;
echo "type fail2ban_t;" >> myfail2ban.te;
echo "')" >> myfail2ban.te;
echo "dontaudit domain fail2ban_t:unix_stream_socket { read write };" >> myfail2ban.te;
echo "')" >> myfail2ban.te;

make -f /usr/share/selinux/devel/Makefile myfail2ban.pp
sudo semodule -i myfail2ban.pp


>
> Thanks again for all your help.
>
> Mark
>
>
> AVCs (I think a couple may be duplicates - I'm running in permissive
> mode):
>
> Raw Audit Messages :
>
> node=troodos.org.uk type=AVC msg=audit(1260298720.4:21): avc: denied { read write } for pid=1907 comm="iptables" path="socket:[16217]" dev=sockfs ino=16217 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket
> node=troodos.org.uk type=SYSCALL msg=audit(1260298720.4:21): arch=40000003 syscall=11 success=yes exit=0 a0=8a1a250 a1=8a1a460 a2=8a19738 a3=8a1a460 items=0 ppid=1906 pid=1907 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="iptables" exe="/sbin/iptables" subj=system_u:system_r:iptables_t:s0 key=(null)
>
> Raw Audit Messages :
>
> node=troodos.org.uk type=AVC msg=audit(1260298720.169:22): avc: denied { read write } for pid=1921 comm="sendmail" path="socket:[16217]" dev=sockfs ino=16217 scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket
> node=troodos.org.uk type=SYSCALL msg=audit(1260298720.169:22): arch=40000003 syscall=11 success=yes exit=0 a0=85867d0 a1=8587798 a2=8587670 a3=8587798 items=0 ppid=1919 pid=1921 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=51 sgid=51 fsgid=51 tty=(none) ses=4294967295 comm="sendmail" exe="/usr/sbin/sendmail.sendmail" subj=system_u:system_r:system_mail_t:s0 key=(null)
>
> Raw Audit Messages :
>
> node=troodos.org.uk type=AVC msg=audit(1260301404.622:121): avc: denied { read write } for pid=2799 comm="iptables" path="socket:[16217]" dev=sockfs ino=16217 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket
> node=troodos.org.uk type=SYSCALL msg=audit(1260301404.622:121): arch=40000003 syscall=11 success=yes exit=0 a0=88b13e0 a1=88b1618 a2=88b06f8 a3=88b1618 items=0 ppid=2798 pid=2799 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="iptables" exe="/sbin/iptables" subj=system_u:system_r:iptables_t:s0 key=(null)
>
> Raw Audit Messages :
>
> node=troodos.org.uk type=AVC msg=audit(1260301405.169:122): avc: denied { read write } for pid=2804 comm="iptables" path="socket:[16217]" dev=sockfs ino=16217 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket
> node=troodos.org.uk type=SYSCALL msg=audit(1260301405.169:122): arch=40000003 syscall=11 success=yes exit=0 a0=96e3418 a1=96e3718 a2=96e2700 a3=96e3718 items=0 ppid=1901 pid=2804 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="iptables" exe="/sbin/iptables" subj=system_u:system_r:iptables_t:s0 key=(null)
>
> Raw Audit Messages :
>
> node=troodos.org.uk type=AVC msg=audit(1260301405.212:123): avc: denied { read write } for pid=2811 comm="sendmail" path="socket:[16217]" dev=sockfs ino=16217 scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket
> node=troodos.org.uk type=SYSCALL msg=audit(1260301405.212:123): arch=40000003 syscall=11 success=yes exit=0 a0=a119518 a1=a119a48 a2=a119750 a3=a119a48 items=0 ppid=2807 pid=2811 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=51 sgid=51 fsgid=51 tty=(none) ses=4294967295 comm="sendmail" exe="/usr/sbin/sendmail.sendmail" subj=system_u:system_r:system_mail_t:s0 key=(null)
>
>



> --
> fedora-selinux-list mailing list
> fedora-selinux-list@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 12-08-2009, 08:15 PM
Arthur Dent
 
Default Selinux & Fail2Ban

On Tue, 2009-12-08 at 21:57 +0100, Dominick Grift wrote:

> > So what do you think?
> >
> > Am I on the right track?
>
> Yes "allow system_mail_t fail2ban_t:unix_stream_socket { read write };", signals a leaked file descriptor on fail2ban. This issue is known. You can ignore those avc denials and/or silence them:

What exactly *is* a "leaked file descriptor"?


> echo "policy_module(myfail2ban, 1.0.0)" > myfail2ban.te;
> echo "optional_policy(`" >> myfail2ban.te;
> echo "gen_require(`" >> myfail2ban.te;
> echo "attribute domain;" >> myfail2ban.te;
> echo "type fail2ban_t;" >> myfail2ban.te;
> echo "')" >> myfail2ban.te;
> echo "dontaudit domain fail2ban_t:unix_stream_socket { read write };" >> myfail2ban.te;
> echo "')" >> myfail2ban.te;

OK - Thanks for this. It's not the way I'm used to generating local
policies and I think there may be an error? Once all the lines are
echo'd into myfail2ban.te this is what I get:
# cat myfail2ban.te

policy_module(myfail2ban, 11.2.1)
optional_policy(`
gen_require(`
attribute domain;
type fail2ban_t;
')
dontaudit domain fail2ban_t:unix_stream_socket { read write };
')

Which won't compile:
> make -f /usr/share/selinux/devel/Makefile myfail2ban.pp
> sudo semodule -i myfail2ban.pp
Gives:

# make -f /usr/share/selinux/devel/Makefile myfail2ban.pp
Compiling targeted myfail2ban module
/usr/bin/checkmodule: loading policy configuration from
tmp/myfail2ban.tmp
myfail2ban.te":2:WARNING 'unrecognized character' at token ' on line
3204:

#line 2
myfail2ban.te":2:WARNING 'unrecognized character' at token ' on line
3214:

#line 2
myfail2ban.te":2:WARNING 'unrecognized character' at token ' on line
3204:

#line 2
myfail2ban.te":2:WARNING 'unrecognized character' at token ' on line
3214:

#line 2
/usr/bin/checkmodule: policy configuration loaded
/usr/bin/checkmodule: writing binary representation (version 10) to
tmp/myfail2ban.mod
Creating targeted myfail2ban.pp policy package
rm tmp/myfail2ban.mod.fc tmp/myfail2ban.mod


I'm not exactly sure what you had in mind otherwise I would edit it to
work...


But thanks again. I do appreciate your help!

Mark

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 12-08-2009, 08:24 PM
Dominick Grift
 
Default Selinux & Fail2Ban

On Tue, Dec 08, 2009 at 09:15:48PM +0000, Arthur Dent wrote:
> On Tue, 2009-12-08 at 21:57 +0100, Dominick Grift wrote:
>
> > > So what do you think?
> > >
> > > Am I on the right track?
> >
> > Yes "allow system_mail_t fail2ban_t:unix_stream_socket { read write };", signals a leaked file descriptor on fail2ban. This issue is known. You can ignore those avc denials and/or silence them:
>
> What exactly *is* a "leaked file descriptor"?
>
>
> > echo "policy_module(myfail2ban, 1.0.0)" > myfail2ban.te;
> > echo "optional_policy(`" >> myfail2ban.te;
> > echo "gen_require(`" >> myfail2ban.te;
> > echo "attribute domain;" >> myfail2ban.te;
> > echo "type fail2ban_t;" >> myfail2ban.te;
> > echo "')" >> myfail2ban.te;
> > echo "dontaudit domain fail2ban_t:unix_stream_socket { read write };" >> myfail2ban.te;
> > echo "')" >> myfail2ban.te;
>
> OK - Thanks for this. It's not the way I'm used to generating local
> policies and I think there may be an error? Once all the lines are
> echo'd into myfail2ban.te this is what I get:
> # cat myfail2ban.te
>
> policy_module(myfail2ban, 11.2.1)
> optional_policy(`
> gen_require(`
> attribute domain;
> type fail2ban_t;
> ')
> dontaudit domain fail2ban_t:unix_stream_socket { read write };
> ')

Your myfail2ban.te file should look like this:

policy_module(myfail2ban, 11.2.1)
optional_policy(`
gen_require(`
attribute domain;
type fail2ban_t;
')
dontaudit domain fail2ban_t:unix_stream_socket { read write };
')

A leaked file descriptor is a programming error it is where the programmer forgot to close a file descriptor (bug in fail2ban)

>
> Which won't compile:
> > make -f /usr/share/selinux/devel/Makefile myfail2ban.pp
> > sudo semodule -i myfail2ban.pp
> Gives:
>
> # make -f /usr/share/selinux/devel/Makefile myfail2ban.pp
> Compiling targeted myfail2ban module
> /usr/bin/checkmodule: loading policy configuration from
> tmp/myfail2ban.tmp
> myfail2ban.te":2:WARNING 'unrecognized character' at token ' on line
> 3204:
>
> #line 2
> myfail2ban.te":2:WARNING 'unrecognized character' at token ' on line
> 3214:
>
> #line 2
> myfail2ban.te":2:WARNING 'unrecognized character' at token ' on line
> 3204:
>
> #line 2
> myfail2ban.te":2:WARNING 'unrecognized character' at token ' on line
> 3214:
>
> #line 2
> /usr/bin/checkmodule: policy configuration loaded
> /usr/bin/checkmodule: writing binary representation (version 10) to
> tmp/myfail2ban.mod
> Creating targeted myfail2ban.pp policy package
> rm tmp/myfail2ban.mod.fc tmp/myfail2ban.mod
>
>
> I'm not exactly sure what you had in mind otherwise I would edit it to
> work...
>
>
> But thanks again. I do appreciate your help!
>
> Mark
>



> --
> fedora-selinux-list mailing list
> fedora-selinux-list@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 12-08-2009, 08:37 PM
Arthur Dent
 
Default Selinux & Fail2Ban

On Tue, 2009-12-08 at 22:24 +0100, Dominick Grift wrote:

>
> Your myfail2ban.te file should look like this:
>
> policy_module(myfail2ban, 11.2.1)
> optional_policy(`
> gen_require(`
> attribute domain;
> type fail2ban_t;
> ')
> dontaudit domain fail2ban_t:unix_stream_socket { read write };
> ')

That did it - Thanks!

> A leaked file descriptor is a programming error it is where the programmer forgot to close a file descriptor (bug in fail2ban)

How can I explain this to the f2b developers so that it can be fixed?

Thanks - yet again!

Mark
--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 12-08-2009, 08:52 PM
"David P. Quigley"
 
Default Selinux & Fail2Ban

On Tue, 2009-12-08 at 21:37 +0000, Arthur Dent wrote:
> On Tue, 2009-12-08 at 22:24 +0100, Dominick Grift wrote:
>
> >
> > Your myfail2ban.te file should look like this:
> >
> > policy_module(myfail2ban, 11.2.1)
> > optional_policy(`
> > gen_require(`
> > attribute domain;
> > type fail2ban_t;
> > ')
> > dontaudit domain fail2ban_t:unix_stream_socket { read write };
> > ')
>
> That did it - Thanks!
>
> > A leaked file descriptor is a programming error it is where the programmer forgot to close a file descriptor (bug in fail2ban)
>
> How can I explain this to the f2b developers so that it can be fixed?
>

So I have copied a small section from Dan Walsh's blog. Its a bit more
than forgetting to close a file descriptor. The problem is that by
default on exec the child process will inherit all file descriptors from
the parent except ones that are closed before exec or marked close on
exec with the fcntl listed below.

One of the interesting things about SELinux is its use to
discover bugs in other code. When I first started working with
SELinux a few years ago, we started discovering a whole bunch of
domains wanting to read and write system_ubject_r:initctl_t
file. This is the context of the /dev/initctl device. After
investigating for a while we found out something in the boot
process was leaking an open file descriptor to /dev/initctl.
This open file descriptor would allow a compromised application
to change the run level of the system. Of course all of these
AVC messages were being reported as bugs in SELinux, but really
they were a serious bug in the boot process. Investigating this
problem further I found that the default behavior of all file
descriptors is to have them inherited over the fork/exec. You
have to execute fcntl(fd, F_SETFD, FD_CLOEXEC); on all file
descriptors that you do not want to be leaked. Needless to say,
lots of programmers forget this and leaked file descriptors are
quite common.

Dan Walsh

> Thanks - yet again!
>
> Mark
> --
> fedora-selinux-list mailing list
> fedora-selinux-list@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 12-09-2009, 06:37 PM
"Göran Uddeborg"
 
Default Selinux & Fail2Ban

Arthur Dent:
> How can I explain this to the f2b developers so that it can be fixed?

For your information: I filed a bug about it a little more than a year
ago:
http://sourceforge.net/tracker/?func=detail&atid=689044&aid=2086568&group_id=1210 32

There hasn't been any action as far as I can tell. But maybe you'll
have more luck if you do a new try now.

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 12-09-2009, 08:41 PM
Daniel J Walsh
 
Default Selinux & Fail2Ban

On 12/09/2009 02:37 PM, Göran Uddeborg wrote:
> Arthur Dent:
>> How can I explain this to the f2b developers so that it can be fixed?
>
> For your information: I filed a bug about it a little more than a year
> ago:
> http://sourceforge.net/tracker/?func=detail&atid=689044&aid=2086568&group_id=1210 32
>
> There hasn't been any action as far as I can tell. But maybe you'll
> have more luck if you do a new try now.
>
> --
> fedora-selinux-list mailing list
> fedora-selinux-list@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>
>
Fail2ban developers are well aware of this, they have been dealing with leaks for a while

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 

Thread Tools




All times are GMT. The time now is 01:03 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org