allowing programs to open ports

[Björn Persson]

Florian Weimer wrote:
>On 12/21/2014 05:28 PM, Björn Persson wrote:
>
>> Alternatively, cut out the packet filter and have GlibC ask the user
>> whether the call to bind or connect shall be allowed to succeed (or
>> automatically allow or deny the call if so configured). This has the
>> advantage that the program is informed that it's not allowed to
>> communicate.
>
>glibc is the wrong place for this, and a patch in this direction has 
>absolutely zero chance of being accepted upstream.  We also ship 
>applications which call system calls directly, not through glibc, so 
>patching glibc would not even work at a technical level.

That's true. The ability to call system calls directly kills the idea of
having GlibC deny the call.

(It does not affect the idea of calling FirewallD from GlibC rather
than from each program individually. Those few programs that do call
system calls directly could still call FirewallD on their own.)

>However, a Linux Security Module such as SELinux could audit socket 
>creation, and provide the user with means to override the default 
>choices.

Yes, that may be an even better solution if there is a way for SElinux 
to ask the user.

>However, this will be extremely controversial (even more so 
>than the open firewall) because it will remind people of “personal 
>firewalls” on Windows.

I bet! I worry that the questions would quickly become annoying. But if
ports are going to be blocked by default, then there needs to be some
way for non-sysadmin users to open them.

-- 
Björn Persson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150103/45ffd0ec/attachment.sig>