2:58 p.m.
Currently policy allows httpd to connect to relay ports and to
mysql/postgres ports.
Adding these booleans
* httpd_can_network_relay
* httpd_can_network_connect_db
And turning this feature off by default. This is going into tonights
reference policy and into FC4 test release.
If we had these turned off we would have prevented the last apache worm
virus.
This could cause problems for people who run httpd relays or have their
apache databases talking to mysql and postgres databases over the network.
You can turn the features back on by executing:
setsebool -P httpd_can_network_relay=1
or
setsebool -P httpd_can_network_connect_db=1
Will consider adding this feature to RHEL in a future update.
Comments?
Dan
--
8:42 a.m.
Daniel J Walsh wrote:
Currently policy allows httpd to connect to relay ports and to
mysql/postgres ports.
Adding these booleans
* httpd_can_network_relay
* httpd_can_network_connect_db
And turning this feature off by default. This is going into tonights
reference policy and into FC4 test release.
If we had these turned off we would have prevented the last apache
worm virus.
This could cause problems for people who run httpd relays or have
their apache databases talking to mysql and postgres databases over
the network.
I'm sorry but I don't understand most of what you write. What is relay
ports? What worm are you refering to?
I find nothing googling and the latest worms I could find was a defect
in apache or openssl.
I'm conserned that this is going in without any discussion, or have I
missed somerhing?
I'm guessing most FC4 users having apache setup are using different kind
of applications in PHP, Python, Perl
etc. that they run. Forums, portals, Wikis, blogs etc. Most, if not all,
uses the network to connect to the local
email server and to store/retreive data from a database. Installing a
policy that breaks their services will be
very determinental to the trust of selinux. I suppose those services
will be left semi-functional after such an update
and that manual intervention is required to restore service. That would
be close to a DOS attack in my oppinion.
You can turn the features back on by executing:
setsebool -P httpd_can_network_relay=1
or
setsebool -P httpd_can_network_connect_db=1
Will consider adding this feature to RHEL in a future update.
Comments?
Please elaborate, what problem is being solved here? What will the
consequences be for end users?
Dan
/Nicke
--
JID nicke(a)im.exinor.net
10:47 a.m.
Nicklas Norling wrote:
Daniel J Walsh wrote:
>
> Currently policy allows httpd to connect to relay ports and to
> mysql/postgres ports.
>
> Adding these booleans
> * httpd_can_network_relay
> * httpd_can_network_connect_db
>
> And turning this feature off by default. This is going into tonights
> reference policy and into FC4 test release.
> If we had these turned off we would have prevented the last apache
> worm virus.
I'd really appreciate if more effort was expanded in fixing existing
AVCs rather than adding new blocking rules.
The current ruleset is already strong enough a lot of people just turn
off selinux, perfect security isn't much use if no one enables it.
I'd rather aim for imperfect security some users actually use.
--
Nicolas Mailhot
11:54 a.m.
Nicolas Mailhot wrote:
Nicklas Norling wrote:
> Daniel J Walsh wrote:
>
>
>> Currently policy allows httpd to connect to relay ports and to
>> mysql/postgres ports.
>>
>> Adding these booleans
>> * httpd_can_network_relay
>> * httpd_can_network_connect_db
>>
>> And turning this feature off by default. This is going into tonights
>> reference policy and into FC4 test release.
>> If we had these turned off we would have prevented the last apache
>> worm virus.
>>
I'd really appreciate if more effort was expanded in fixing existing
AVCs rather than adding new blocking rules.
Which avc's are you talking about. We have been working hard to fix all
avc's when we can.
The current ruleset is already strong enough a lot of people just
turn
off selinux, perfect security isn't much use if no one enables it.
Most people turned off firewall support in the beginning also. These
rules should not effect 90 % of apache SELinux users
and will further secure those same users.
I'd rather aim for imperfect security some users actually use.
We are trying to work to a happy medium of security with as little pain
as possible.
--
1:08 p.m.
On Sam 10 décembre 2005 18:54, Daniel J Walsh wrote:
Nicolas Mailhot wrote:
> I'd really appreciate if more effort was expanded in fixing
existing
> AVCs rather than adding new blocking rules.
>
Which avc's are you talking about. We have been working hard to fix all
avc's when we can.
How about having selinux play nice with spamassassin at last ?
It's still not able to create resolver sockets
"Error creating a DNS resolver socket"
or writing in its own files
cannot create tmp lockfile ~/.spamassassin/bayes.lock.xxx
cannot write to ~/.spamassassin/user_pref
(this has been reported many many times)
Or else fix fstab-sync
avc: denied { getattr } for pid=2572 comm="fstab-sync" name="/"
dev=tmpfs ino=5287 scontext=system_u:system_r:updfstab_t:s0
tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir
(again, reported many times)
Or else not break basic stuff like thunderbird
avc: denied { execmem } for pid=2950 comm="thunderbird-bin"
scontext=user_u:system_r:unconfined_t:s0-s0:c0.c255
tcontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 tclass=process
or gpm
avc: denied { write } for pid=2420 comm="gpm" name="mice"
dev=tmpfs
ino=4118 scontext=system_u:system_r:gpm_t:s0
tcontext=system_u:object_r:mouse_device_t:s0 tclass=chr_file
these two are new, but since I spare you the stuff which has been fixed
lately I figured it was only fair to add new breakage
# audit2allow </var/log/audit/audit.log
allow dovecot_auth_t dovecot_var_run_t:dir search;
allow dovecot_auth_t tmp_t:dir getattr;
allow dovecot_auth_t usr_t:lnk_file read;
allow gpm_t mouse_device_t:chr_file write;
allow sysadm_su_t etc_runtime_t:file read;
allow sysadm_su_t tmp_t:dir getattr;
allow sysadm_su_t usr_t:lnk_file read;
allow unconfined_t self:process execmem;
allow updfstab_t tmpfs_t:dir getattr;
This with selinux-policy-targeted-2.1.2-1
I'd like to write there is some progress, but the length of my AVC list
seems to be stable over time, new stuff breaks as often as old stuff gets
fixed, and the overall length is not shrinking.
Regards,
--
Nicolas Mailhot
2:37 p.m.
Nicolas Mailhot wrote:
avc: denied { execmem } for pid=2950
comm="thunderbird-bin"
scontext=user_u:system_r:unconfined_t:s0-s0:c0.c255
tcontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 tclass=process
If this really happens then this is a terrible bug in tbird. It's
nothing which should be patched with the policy. By not adding the
support to catch these problems early the code won't be fixed.
New rules are often added for a specific purpose: discover bugs in
programs and stop existing threats. It would be wrong to not attack
these as soon as possible.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
2:59 p.m.
On Sam 10 décembre 2005 21:37, Ulrich Drepper wrote:
Nicolas Mailhot wrote:
> avc: denied { execmem } for pid=2950 comm="thunderbird-bin"
> scontext=user_u:system_r:unconfined_t:s0-s0:c0.c255
> tcontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 tclass=process
If this really happens then this is a terrible bug in tbird. It's
nothing which should be patched with the policy. By not adding the
support to catch these problems early the code won't be fixed.
New rules are often added for a specific purpose: discover bugs in
programs and stop existing threats. It would be wrong to not attack
these as soon as possible.
It really happens, at least there (and thunderbird hasn't been updated,
only selinux was - so it was happening before).
So there are lots of work to do with existing rules before even thinking
of moving to new bits like httpd port policy.
--
Nicolas Mailhot
3:38 p.m.
Nicolas Mailhot wrote:
So there are lots of work to do with existing rules before even
thinking
of moving to new bits like httpd port policy.
You do not understand the situation and my comments at all: the changes
which cause problems due to execmod and execmem errors must be fixed in
the programs. "Adding" these errors in independent of fixing up the
policy for currently failing but valid programs.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
1:27 p.m.
On Sat, 2005-12-10 at 20:08 +0100, Nicolas Mailhot wrote:
How about having selinux play nice with spamassassin at last ?
It's still not able to create resolver sockets
"Error creating a DNS resolver socket"
This is fixed upstream.
or writing in its own files
cannot create tmp lockfile ~/.spamassassin/bayes.lock.xxx
cannot write to ~/.spamassassin/user_pref
You didn't say what the denial was. I went looking, and only found this
on the mail list:
On Sun, 2005-11-20 at 08:52 -0700, W. Scott Wilburn wrote:
Nov 20 04:05:44 scooby kernel: audit(1132484744.807:45387): avc:
denied
{ search } for pid=25548 comm="spamd" name=".spamassassin" dev=md0
ino=2197675 scontext=root:system_r:spamd_t
tcontext=user_u:object_r:user_home_t tclass=dir
Is this the denial that corresponds to the messages you have above?
Or else fix fstab-sync
avc: denied { getattr } for pid=2572 comm="fstab-sync" name="/"
dev=tmpfs ino=5287 scontext=system_u:system_r:updfstab_t:s0
tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir
Fixed upstream.
or gpm
avc: denied { write } for pid=2420 comm="gpm" name="mice"
dev=tmpfs
ino=4118 scontext=system_u:system_r:gpm_t:s0
tcontext=system_u:object_r:mouse_device_t:s0 tclass=chr_file
Fixed upstream.
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150
2:06 p.m.
On Lun 12 décembre 2005 20:27, Christopher J. PeBenito wrote:
On Sat, 2005-12-10 at 20:08 +0100, Nicolas Mailhot wrote:
> How about having selinux play nice with spamassassin at last ?
>
> It's still not able to create resolver sockets
> "Error creating a DNS resolver socket"
This is fixed upstream.
I think it is in spamd context but not in procmail context.
> or writing in its own files
>
> cannot create tmp lockfile ~/.spamassassin/bayes.lock.xxx
> cannot write to ~/.spamassassin/user_pref
You didn't say what the denial was.
A lot of traces where attached in redhat bugzilla entries.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172088
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172496
They no longuer appear in audit.log - I suspect /homes accesses are now
filtered by default
(when the problem was first reported a few weeks ago they did appear as AVCs)
The tricky bit is most of them are executed for the home user, but in
procmail context.
Regards,
--
Nicolas Mailhot
12:03 p.m.
Nicklas Norling wrote:
Daniel J Walsh wrote:
>
> Currently policy allows httpd to connect to relay ports and to
> mysql/postgres ports.
>
> Adding these booleans
> * httpd_can_network_relay
> * httpd_can_network_connect_db
>
> And turning this feature off by default. This is going into tonights
> reference policy and into FC4 test release.
> If we had these turned off we would have prevented the last apache
> worm virus.
> This could cause problems for people who run httpd relays or have
> their apache databases talking to mysql and postgres databases over
> the network.
>
I'm sorry but I don't understand most of what you write. What is relay
ports? What worm are you refering to?
In the default targeted policy in FC4/RHEL4
apache is allowed to attach
to the Apache ports 80. 8080 and a few others like ftp etc. This
boolean would allow users who do not want their apache servers to be
able to connect out. Most apache servers do not relay requests to other
machines, and this would just enforce this policy. A worm that came out
over the last couple of months attacked PHP and apache and once a
machine was infected launched attacks on other web servers inside your
private network. If the new policy was in place this worm/attack would
have been thwarted. Apache currently is not allowed to connect to
random ports including the mail port. You have to turn that on a
boolean if you want apache to connect to these other ports. These new
booleans would just close all remaining ports that apache could connect to.
I find nothing googling and the latest worms I could find was a
defect
in apache or openssl.
I'm conserned that this is going in without any discussion, or have I
missed somerhing?
This is the discussion. I have not put out a fc4 RELEASE YET. I
am
looking for peoples comments before we turn this on.
I'm guessing most FC4 users having apache setup are using
different
kind of applications in PHP, Python, Perl
etc. that they run. Forums, portals, Wikis, blogs etc. Most, if not
all, uses the network to connect to the local
email server and to store/retreive data from a database.
Connecting to the local
database should not be a problem, since that
would be over a unix domain socket. Mail is currently shut off and you
need to turn on boolean to allow it.
Installing a policy that breaks their services will be
very determinental to the trust of selinux. I suppose those services
will be left semi-functional after such an update
and that manual intervention is required to restore service. That
would be close to a DOS attack in my oppinion.
We could leave the boolean turned on, but then most customers would not
get the security increase.
> You can turn the features back on by executing:
> setsebool -P httpd_can_network_relay=1
> or
> setsebool -P httpd_can_network_connect_db=1
>
> Will consider adding this feature to RHEL in a future update.
>
> Comments?
Please elaborate, what problem is being solved here? What will the
consequences be for end users?
It will prevent a hacked Apache/PHP server from being able to launch
attacks on other servers. The consequences for most users would be
nil. Some will break their service, until they set the boolean, if we
default to off.
>
> Dan
>
/Nicke
--
1:05 p.m.
Daniel J Walsh wrote:
Connecting to the local database should not be a problem, since that
would be over a unix domain socket. Mail is currently shut off and you
need to turn on boolean to allow it.
Please don't make this assumption. A lot of web application authors
don't bother to enable this (assuming that the database, the web
scripting language, and the connection software all support it), so it's
necessary to use a network connection over the loopback adapter.
--
========================================================================
Ian Pilcher i.pilcher(a)comcast.net
========================================================================
5:02 a.m.
On Fri, Dec 09, 2005 at 03:58:14PM -0500, Daniel J Walsh wrote:
Currently policy allows httpd to connect to relay ports and to
mysql/postgres ports.
Adding these booleans
* httpd_can_network_relay
* httpd_can_network_connect_db
And turning this feature off by default. This is going into tonights
reference policy and into FC4 test release.
Do you mean FC4 or FC5? This should not go in an FC4 update
off-by-default since it will break working setups. Make it
on-by-default if you want to ship this to FC4 users and off-by-default
with a big release note for FC5.
What's the difference between httpd_can_network_relay and
httpd_can_network_connect?
Do we still have the problem that httpd cannot reap idle children
properly when the latter is set? That really really does need to work
by default.
joe
7:29 p.m.
Joe Orton wrote:
On Fri, Dec 09, 2005 at 03:58:14PM -0500, Daniel J Walsh wrote:
>Currently policy allows httpd to connect to relay ports and to
>mysql/postgres ports.
>
>Adding these booleans
> * httpd_can_network_relay
> * httpd_can_network_connect_db
>
>And turning this feature off by default. This is going into tonights
>reference policy and into FC4 test release.
>
>
Do you mean FC4 or FC5? This should not go in an FC4 update
off-by-default since it will break working setups. Make it
on-by-default if you want to ship this to FC4 users and off-by-default
with a big release note for FC5.
What's the difference between httpd_can_network_relay and
httpd_can_network_connect?
Do we still have the problem that httpd cannot reap idle children
properly when the latter is set? That really really does need to work
by default.
joe
--
fedora-selinux-list mailing list
fedora-selinux-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
I'd like to completely agree with Joe. I'm beginning to have quite a lot
invested in httpd, PHP and related database code and I don't want
SELinux breaking what is there without a lot of warning. For new
installs of FC4, I've been forced to turn off SELinux support for these
applications. They simply don't work otherwise.
Bob Cochran
Greenbelt. Maryland, USA
10:15 p.m.
Robert L Cochran wrote:
Joe Orton wrote:
> On Fri, Dec 09, 2005 at 03:58:14PM -0500, Daniel J Walsh wrote:
>
>
>> Currently policy allows httpd to connect to relay ports and to
>> mysql/postgres ports.
>>
>> Adding these booleans
>> * httpd_can_network_relay
>> * httpd_can_network_connect_db
>>
>> And turning this feature off by default. This is going into
>> tonights reference policy and into FC4 test release.
>>
>
> Do you mean FC4 or FC5? This should not go in an FC4 update
> off-by-default since it will break working setups. Make it
> on-by-default if you want to ship this to FC4 users and
> off-by-default with a big release note for FC5.
>
> What's the difference between httpd_can_network_relay and
> httpd_can_network_connect?
>
> Do we still have the problem that httpd cannot reap idle children
> properly when the latter is set? That really really does need to
> work by default.
>
> joe
>
> --
> fedora-selinux-list mailing list
> fedora-selinux-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>
>
>
>
I'd like to completely agree with Joe. I'm beginning to have quite a
lot invested in httpd, PHP and related database code and I don't want
SELinux breaking what is there without a lot of warning. For new
installs of FC4, I've been forced to turn off SELinux support for
these applications. They simply don't work otherwise.
Bob Cochran
Greenbelt. Maryland, USA
Have your reported your problems here or in bugzilla?
--
8:46 a.m.
VMWare has problems with execmem as previously reported:
type=AVC msg=audit(1134338328.000:56): avc: denied { execmem } for
pid=5215 comm="ld-linux.so.2"
scontext=root:system_r:unconfined_t:s0-s0:c0.c255
tcontext=root:system_r:unconfined_t:s0-s0:c0.c255 tclass=process
type=SYSCALL msg=audit(1134338328.000:56): arch=40000003 syscall=125
success=no exit=-13 a0=bfc78000 a1=1000 a2=1000007 a3=98b6e0 items=0
pid=5215 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 comm="ld-linux.so.2" exe="/lib/ld-2.3.90.so"
and
time->Sun Dec 11 13:05:51 2005
type=AVC_PATH msg=audit(1134335151.660:39):
path="/usr/lib/vmware/lib/libgdk-x11-2.0.so.0/libgdk-x11-2.0.so.0"
type=SYSCALL msg=audit(1134335151.660:39): arch=40000003 syscall=125 per=400000
success=no exit=-13 a0=b7c99000 a1=7b000 a2=5 a3=bfc5a1e0 items=0
pid=4418 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 comm="vmware" exe="/usr/lib/vmware/bin/vmware"
type=AVC msg=audit(1134335151.660:39): avc: denied { execmod } for
pid=4418 comm="vmware" name="libgdk-x11-2.0.so.0" dev=dm-0 ino=343461
scontext=root:system_r:unconfined_t:s0-s0:c0.c255
tcontext=system_u:object_r:lib_t:s0 tclass=file
Reply from VMware on my complaint about execmem issues:
As your system refuses to execute even /lib/ld-2.3.90.so (if I
understand it correctly), you seems to have some problem...
None of VMware parts (at least I believe) require executable stack or
heap. Applications which need it explicitly call mmap with PROT_EXEC.
Another question is whether libraries we ship are correctly tagged to
signal this - but it should not be problem as you can install all
libraries VMware needs from your distribution, VMware just ships
libraries it was linked with as it is simpler for us to ship you
libgdk-whatever than (finding and) explaining that you must to install
some-strange-package-with-no-gdk-in-filename to get VMware to work. On
"correct" system with all libraries you should be able to run vmware
directly by /usr/lib/vmware/bin/vmware. Apparently your system is
missing at least openssl097...
--------------------------------------------
My understanding from this thread on how execmem works is that calling
mmap with PROT_EXEC can (will?) still trigger execmem. Right?
Here is the link to the discussion thread: Please hop on to help/clarify!
http://www.vmware.com/community/thread.jspa?messageID=320149񎊕
thanks,
tom
--
Tom London
4:24 p.m.
Daniel J Walsh wrote:
Robert L Cochran wrote:
> Joe Orton wrote:
>
>> On Fri, Dec 09, 2005 at 03:58:14PM -0500, Daniel J Walsh wrote:
>>
>>
>>> Currently policy allows httpd to connect to relay ports and to
>>> mysql/postgres ports.
>>>
>>> Adding these booleans
>>> * httpd_can_network_relay
>>> * httpd_can_network_connect_db
>>>
>>> And turning this feature off by default. This is going into
>>> tonights reference policy and into FC4 test release.
>>>
>>
>>
>> Do you mean FC4 or FC5? This should not go in an FC4 update
>> off-by-default since it will break working setups. Make it
>> on-by-default if you want to ship this to FC4 users and
>> off-by-default with a big release note for FC5.
>>
>> What's the difference between httpd_can_network_relay and
>> httpd_can_network_connect?
>>
>> Do we still have the problem that httpd cannot reap idle children
>> properly when the latter is set? That really really does need to
>> work by default.
>>
>> joe
>>
>> --
>> fedora-selinux-list mailing list
>> fedora-selinux-list(a)redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>>
>>
>>
>>
> I'd like to completely agree with Joe. I'm beginning to have quite a
> lot invested in httpd, PHP and related database code and I don't want
> SELinux breaking what is there without a lot of warning. For new
> installs of FC4, I've been forced to turn off SELinux support for
> these applications. They simply don't work otherwise.
>
> Bob Cochran
> Greenbelt. Maryland, USA
>
>
Have your reported your problems here or in bugzilla?
Yes I reported an error in fedora-selinux-list with this subject line:
"MySQL 5.0.4 Beta AVC Denied Messages". That was back in May, there was
no reply to the post. I don't think I've put anything in bugzilla. I
fixed the error by removing SELinux protection for the MySQL
application. I believe, but need to confirm, that I also turned it off
for php (I compile a lot of snapshots from snaps.php.net) on that
machine, too. I have since upgraded the machine to Fedora Core 4.
I can't remember whether I set that machine up with SELinux in
permissive or enforcing mode. But when I later installed MySQL 5 from
rpm's downloaded from dev.mysql.com, SELinux broke the startup script by
denying mysqld permission to start and thereby build the grant tables,
etc. Until a better solution comes along, I don't want SELinux breaking
my applications in this way. As a matter of fact, one enhancement I'd
like to see is SELinux emitting a user-friendly message in the logs
explaining how to turn on the functionality for an application it has
just denied. Something like this:
To turn this functionality on, go to Desktop --> System Settings --->
Security Level --> SELinux and....[more precise instructions presented
here].
It would also be nice to have preconfigured "application access levels"
an administrator can turn on or off rapidly. For example, if the machine
is intended to be used as a firewall, have an application access level
that would configure SELinux to let the right kind of firewall services
(iptables, for example) run correctly. This access level would be set up
to prevent gcc, perl, ruby or any other compiler from working if
installed. The idea is to introduce ease of use and adminstration to
SELinux.
I'm not an SELinux expert; I'm just trying to administer my own machines
on my own network and go about application development with a minimum of
interference and pain from security type software. If I can't get
SELinux to cooperate with me a little and provide a smooth solution for
not breaking my applications, I'll simply turn it off.
Bob Cochran
9:31 p.m.
Here is the response from vmware:
VMware generates lots of code on the fly, so flipping PROT_EXEC with
PROT_WRITE would not reasonably work. Especially not in the
multithreaded environment where it would continuously cause IPIs to be
send between processors, slowing down everything. If SELinux default
policy authors decided that they cannot trust applications, then I'm
afraid that you'll have to create special policy for VMware.
libgdk-x11's library from vmware's directory will be used only if
libraries on your host are found to be inadequate. Try
'VMWARE_USE_SHIPPED_GTK=no vmware' and it should tell you which
libraries are missing on your box. After you'll install them then
libgdk-x11 from /usr/lib should be used.
-------------------------------------------------------------
I haven't gotten the library test working yet.....
tom
--
Tom London
10:14 p.m.
Joe Orton wrote:
On Fri, Dec 09, 2005 at 03:58:14PM -0500, Daniel J Walsh wrote:
> Currently policy allows httpd to connect to relay ports and to
> mysql/postgres ports.
>
> Adding these booleans
> * httpd_can_network_relay
> * httpd_can_network_connect_db
>
> And turning this feature off by default. This is going into tonights
> reference policy and into FC4 test release.
>
Do you mean FC4 or FC5? This should not go in an FC4 update
off-by-default since it will break working setups. Make it
on-by-default if you want to ship this to FC4 users and off-by-default
with a big release note for FC5.
Ok plan is to add this to FC4 With relay and database network connect
turned on by default.
What's the difference between httpd_can_network_relay and
httpd_can_network_connect?
They are just more specific. They allow specific connections to relay
ports (http, ftp, gopher etc) and database ports (mysql and postgres).
Do we still have the problem that httpd cannot reap idle children
properly when the latter is set? That really really does need to work
by default.
Do you have a bugzilla for this?
joe
--
6721
days inactive
6726
days old
selinux@lists.fedoraproject.org
18 comments
9 participants
participants (9)
-
Christopher J. PeBenito -
Daniel J Walsh -
Ian Pilcher -
Joe Orton -
Nicklas Norling -
Nicolas Mailhot -
Robert L Cochran -
Tom London -
Ulrich Drepper