ufw package integration

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

ufw package integration

Jamie Strandboge-3
With the upload of ufw 0.20 to Intrepid yesterday, ufw now supports
application (package) integration. This allows packages to declare their
ports and protocols to ufw, so user's can specify an application profile
when adding and removing rules. Application profiles can be thought of
as simply port/protocol groups that are referenced by name.

For example, when apache is installed, it could add a file to
/etc/ufw/applications.d which declares it as running on tcp port 80.
User's could then do:
$ sudo ufw allow Apache

The equivalent non-profile command is:
$ sudo ufw allow 80/tcp

While this is somewhat more convenient for users, things get more
interesting when packages declare multiple profiles, eg 'Apache',
'Apache Secure' and 'Apache Full', which could correspond to 80/tcp,
443/tcp and 80,443/tcp respectively. This becomes even more useful when
an application has several port/protocol combinations, such as Samba,
which might declare 137,138/udp and 139,445/tcp.

ufw also allows changing a profile, then updating all rules referencing
the profile. Eg, say an administrator adds a profile called 'Custom Web
App', which listens on 8080/tcp. A user then runs "ufw allow 'Custom Web
App'". Later the administrator adds 8081/tcp. A user can then run "ufw
app update 'Custom Web App'" which will update the firewall to allow
both 8080/tcp and 8081/tcp.

Finally, ufw can be configured to automatically add a rule when a user
runs 'ufw app update --add-new <profile>'. The default policy for the
new rule is configured using 'ufw app default <policy>'. The default
policy is 'skip' which will not add a new rule automatically, as well as
allow and deny.

Technically, groupings are accomplished by using the iptables '-m
comment' option. All grouped rules have the same comment which
references the profile name, which avoids collisions. Added rules still
remain after profile removal and users can delete rules referencing
these removed profiles. Application integration can be used with ufw's
simple and extended syntax. See 'man ufw' and [1] for details and status.

Help is needed in adding profiles to various packages. The changes
needed and testing procedures are documented in [2], while some targeted
packages are listed in [3]. This is a great way to get involved and
improve one's packaging skills. Please create new bug reports with
debdiffs attached, and I or someone from the Ubuntu Server team can
upload the updated package.

Thanks and enjoy!

Jamie

[1] https://wiki.ubuntu.com/UbuntuFirewall
[2] https://wiki.ubuntu.com/UbuntuFirewall#Integrating%20UFW%20with%20Packages
[3] https://wiki.ubuntu.com/ServerTeam/Roadmap#UFW%20Package%20Integration

--
Ubuntu Security Engineer     | http://www.ubuntu.com/
Canonical Ltd.               | http://www.canonical.com/

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ufw package integration

James Dinkel-2
On Tue, Aug 19, 2008 at 4:05 PM, Jamie Strandboge <[hidden email]> wrote:
With the upload of ufw 0.20 to Intrepid yesterday, ufw now supports
application (package) integration. This allows packages to declare their
<snip>

Jamie


This sounds like a good idea.  I can tell you it took me a while to figure out what ports Samba needed.  I had googled for it, and apparently found innaccurate or old information (this was before I knew about netstat).  Anyway, this should make it much simpler.

I do have one suggestion though.  I am the type of sysadmin who likes to know exactly what is going on with his system (which is probably why I generally like text editing config files over gui interfaces), so it would be nice if a short message after running the command would tell you what ports were being opened (I know I could just look over the config file, but to make things easier...).  Such as:

$ sudo ufw allow Apache-Full
Opening 80,443/tcp

This would give me some peace of mind to know it is opening the ports I want, and also be convenient for services with unkown ports in case I would need to open those ports on an external firewall appliance.

James

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: ufw package integration

Steve Langasek-6
In reply to this post by Jamie Strandboge-3
On Tue, Aug 19, 2008 at 05:05:44PM -0400, Jamie Strandboge wrote:
> With the upload of ufw 0.20 to Intrepid yesterday, ufw now supports
> application (package) integration. This allows packages to declare their
> ports and protocols to ufw, so user's can specify an application profile
> when adding and removing rules. Application profiles can be thought of
> as simply port/protocol groups that are referenced by name.

> For example, when apache is installed, it could add a file to
> /etc/ufw/applications.d which declares it as running on tcp port 80.

If the files are installed in /etc/, then they have to be config files
(conffiles or otherwise).  Config files are left installed when packages are
removed, and deleted only on package purge.  How does this design prevent
leaving ports open when the package that they legitimately correspond to is
no longer installed?

--
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
[hidden email]                                     [hidden email]

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: ufw package integration

Nicolas Valcárcel Scerpella
On Wed, 2008-09-03 at 17:33 -0700, Steve Langasek wrote:
> How does this design prevent
> leaving ports open when the package that they legitimately correspond
> to is
> no longer installed?

I think we can (if it's not already preventing it) add a command
on .postrm that disables it on ufw. At the end this files are just for
declaring profiles, not enabling or open any port, they just describe a
service ports so the user doesn't need to care about them just enable
that service on ufw. So we don't need to care about those files opening
any port, but for disabling them on ufw after removing.

--
aka nxvl
Key fingerprint = BCE4 27A0 D03E 55DE DA2D  BE06 891D 8DEE 6545 97FE
gpg --keyserver keyserver.ubuntu.com --recv-keys 654597FE



--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: ufw package integration

Dennis Kaarsemaker
In reply to this post by Steve Langasek-6
On wo, 2008-09-03 at 17:33 -0700, Steve Langasek wrote:

> On Tue, Aug 19, 2008 at 05:05:44PM -0400, Jamie Strandboge wrote:
> > With the upload of ufw 0.20 to Intrepid yesterday, ufw now supports
> > application (package) integration. This allows packages to declare their
> > ports and protocols to ufw, so user's can specify an application profile
> > when adding and removing rules. Application profiles can be thought of
> > as simply port/protocol groups that are referenced by name.
>
> > For example, when apache is installed, it could add a file to
> > /etc/ufw/applications.d which declares it as running on tcp port 80.
>
> If the files are installed in /etc/, then they have to be config files
> (conffiles or otherwise).  Config files are left installed when packages are
> removed, and deleted only on package purge.  How does this design prevent
> leaving ports open when the package that they legitimately correspond to is
> no longer installed?
Something similar as for initscripts, which also linger around?

test -e $DAEMON || exit 0
--
Dennis K.

The universe tends towards maximum irony. Don't push it.

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ufw package integration

Didier Roche-2
In reply to this post by Nicolas Valcárcel Scerpella

2008/9/4 Nicolas Valcárcel <[hidden email]>

On Wed, 2008-09-03 at 17:33 -0700, Steve Langasek wrote:
> How does this design prevent
> leaving ports open when the package that they legitimately correspond
> to is
> no longer installed?

I think we can (if it's not already preventing it) add a command
on .postrm that disables it on ufw. At the end this files are just for
declaring profiles, not enabling or open any port, they just describe a
service ports so the user doesn't need to care about them just enable
that service on ufw. So we don't need to care about those files opening
any port, but for disabling them on ufw after removing.


The issue is more complex than that. Because you do not know which profile is currently loaded (they can be more than one profile by package.
A typical example is Apache which has 3 profiles: one for port 80, one for 443 and the last one for both of them.

An idea might be to force (without watching at the error in case the profile is not associated to a rule) the removal of the corresponding rules by doing "sudo ufw delete allow <profile>" on all profiles of the package (and even "sudo ufw delete deny <profile>"/"sudo ufw delete limit <profile>". Maybe a "sudo ufw delete any_policy <profile>" will be a good new command).

What is the case if another package use the same port and had it opened (with ufw profile integration)? Does the port is still open on the firewall (which is what we really want)?

PS: Sorry Nicolas. I really have to get rid of gmail with its ML management...

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: ufw package integration

James Dinkel-2
On Thu, Sep 4, 2008 at 5:11 AM, Didier Roche <[hidden email]> wrote:

2008/9/4 Nicolas Valcárcel <[hidden email]>

On Wed, 2008-09-03 at 17:33 -0700, Steve Langasek wrote:
> How does this design prevent
> leaving ports open when the package that they legitimately correspond
> to is
> no longer installed?

I think we can (if it's not already preventing it) add a command
on .postrm that disables it on ufw. At the end this files are just for
declaring profiles, not enabling or open any port, they just describe a
service ports so the user doesn't need to care about them just enable
that service on ufw. So we don't need to care about those files opening
any port, but for disabling them on ufw after removing.


The issue is more complex than that. Because you do not know which profile is currently loaded (they can be more than one profile by package.
A typical example is Apache which has 3 profiles: one for port 80, one for 443 and the last one for both of them.

An idea might be to force (without watching at the error in case the profile is not associated to a rule) the removal of the corresponding rules by doing "sudo ufw delete allow <profile>" on all profiles of the package (and even "sudo ufw delete deny <profile>"/"sudo ufw delete limit <profile>". Maybe a "sudo ufw delete any_policy <profile>" will be a good new command).

What is the case if another package use the same port and had it opened (with ufw profile integration)? Does the port is still open on the firewall (which is what we really want)?

I would say leave the ports open and leave the profile files.  Leave it up to the user to manage the firewall.  If the package is removed, it's not going to be listening on those ports any more anyway.

James

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: ufw package integration

Cody A.W. Somerville


On Thu, Sep 4, 2008 at 11:58 AM, James Dinkel <[hidden email]> wrote:
On Thu, Sep 4, 2008 at 5:11 AM, Didier Roche <[hidden email]> wrote:

2008/9/4 Nicolas Valcárcel <[hidden email]>

On Wed, 2008-09-03 at 17:33 -0700, Steve Langasek wrote:
> How does this design prevent
> leaving ports open when the package that they legitimately correspond
> to is
> no longer installed?

I think we can (if it's not already preventing it) add a command
on .postrm that disables it on ufw. At the end this files are just for
declaring profiles, not enabling or open any port, they just describe a
service ports so the user doesn't need to care about them just enable
that service on ufw. So we don't need to care about those files opening
any port, but for disabling them on ufw after removing.


The issue is more complex than that. Because you do not know which profile is currently loaded (they can be more than one profile by package.
A typical example is Apache which has 3 profiles: one for port 80, one for 443 and the last one for both of them.

An idea might be to force (without watching at the error in case the profile is not associated to a rule) the removal of the corresponding rules by doing "sudo ufw delete allow <profile>" on all profiles of the package (and even "sudo ufw delete deny <profile>"/"sudo ufw delete limit <profile>". Maybe a "sudo ufw delete any_policy <profile>" will be a good new command).

What is the case if another package use the same port and had it opened (with ufw profile integration)? Does the port is still open on the firewall (which is what we really want)?

I would say leave the ports open and leave the profile files.  Leave it up to the user to manage the firewall.  If the package is removed, it's not going to be listening on those ports any more anyway.

Why don't we just leave all ports open then? :P
 


James

--
ubuntu-server mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam



--
Cody A.W. Somerville
Software Systems Release Engineer
Custom Engineering Solutions Group
Canonical OEM Services
Cell: 506-449-5899
Email: [hidden email]

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: ufw package integration

Soren Hansen-2
In reply to this post by James Dinkel-2
On Thu, Sep 04, 2008 at 09:58:40AM -0500, James Dinkel wrote:
> I would say leave the ports open and leave the profile files.  Leave
> it up to the user to manage the firewall.  If the package is removed,
> it's not going to be listening on those ports any more anyway.

If "not listening" was sufficient, there'd be little point in having a
firewall in the first place, wouldn't there?

--
Soren Hansen               |
Virtualisation specialist  | Ubuntu Server Team
Canonical Ltd.             | http://www.ubuntu.com/

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (324 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ufw package integration

James Dinkel-2
On Thu, Sep 4, 2008 at 10:39 AM, Soren Hansen <[hidden email]> wrote:
On Thu, Sep 04, 2008 at 09:58:40AM -0500, James Dinkel wrote:
> I would say leave the ports open and leave the profile files.  Leave
> it up to the user to manage the firewall.  If the package is removed,
> it's not going to be listening on those ports any more anyway.

If "not listening" was sufficient, there'd be little point in having a
firewall in the first place, wouldn't there?

--
Soren Hansen

Well, 'not listening' _should_ be sufficient, however I prefer (and suggest) to use a firewall as an extra layer of protection.  I must have been mistaken, I did not realize we were debating the merits of a firewall, only whether or not packages should automatically change firewall rules.  Of course, if I trusted packages to manage opening and closing their own firewall rules, then I might as well trust them to listen or not on those ports, so in that case then yes there would be little point in having a firewall in the first place.

James

On Thu, Sep 4, 2008 at 10:02 AM, Cody A.W. Somerville <[hidden email]> wrote:

Why don't we just leave all ports open then? :P

--
Cody A.W. Somerville[hidden email]


Well, for a long time that was the standard setup for Ubuntu.  As I mentioned above though, I would suggest using a firewall with all ports blocked by default as an additional layer of protection.

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: ufw package integration

Luke L
Should package integration be disabled by default? I know a lot of Linux people who are a little unsettled by how much Ubuntu attempts to automate things, without users' control or knowledge. Not all those arguments hold water, but if a firewall were opening and closing ports on a system without the admin's express, explicit consent, it  could quickly drive away the users this could benefit.

As the disclaimer goes with EVERY post I make to the MLs here: I am not an expert, and I am not an active developer here. I am asking that it be considered, if it hasn't already, that package integration be an optional, if not disabled-by-default, feature. Let the admin know (with confirmation) that package integration is on, and that the OS will attempt to "inetlligently" (emphasis on quotes) adjust firewall settings based on installed programs.

It could be argued that if someone wants full control over their firewall they could just use iptables, but meh.

On Thu, Sep 4, 2008 at 10:58 AM, James Dinkel <[hidden email]> wrote:
On Thu, Sep 4, 2008 at 10:39 AM, Soren Hansen <[hidden email]> wrote:
On Thu, Sep 04, 2008 at 09:58:40AM -0500, James Dinkel wrote:
> I would say leave the ports open and leave the profile files.  Leave
> it up to the user to manage the firewall.  If the package is removed,
> it's not going to be listening on those ports any more anyway.

If "not listening" was sufficient, there'd be little point in having a
firewall in the first place, wouldn't there?

--
Soren Hansen

Well, 'not listening' _should_ be sufficient, however I prefer (and suggest) to use a firewall as an extra layer of protection.  I must have been mistaken, I did not realize we were debating the merits of a firewall, only whether or not packages should automatically change firewall rules.  Of course, if I trusted packages to manage opening and closing their own firewall rules, then I might as well trust them to listen or not on those ports, so in that case then yes there would be little point in having a firewall in the first place.

James

On Thu, Sep 4, 2008 at 10:02 AM, Cody A.W. Somerville <[hidden email]> wrote:

Why don't we just leave all ports open then? :P

--
Cody A.W. Somerville[hidden email]


Well, for a long time that was the standard setup for Ubuntu.  As I mentioned above though, I would suggest using a firewall with all ports blocked by default as an additional layer of protection.

--
ubuntu-server mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam



--
Luke L.

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: ufw package integration

Silvio Fonseca
On Thursday 04 September 2008 18:55:41 Luke L wrote:
I second that. I'm also a new guy here but consider these two small examples:

- When you install a DNS server (e.g. bind), it listens on UDP 53 for normal
DNS requests and TCP 53 for zone transfer requests. The package could not
possibly know who should be allowed to query or transfer zones to/from this
server.

- When you install a Mail server (e.g. postfix), again, package can't know if
this is just an internal mail server, a relay for a specific server pool or a
public server.

If I enable ufw is because I want to protect a service, it has no use if the
package itself open up the ports.

With that said, it will be of great help if the package can provide a template
with the ports used by the package so the admin can just adjust the rules and
enable the protection.

Just my 2 cents.

Silvio Fonseca

> Should package integration be disabled by default? I know a lot of Linux
> people who are a little unsettled by how much Ubuntu attempts to automate
> things, without users' control or knowledge. Not all those arguments hold
> water, but if a firewall were opening and closing ports on a system without
> the admin's express, explicit consent, it  could quickly drive away the
> users this could benefit.
>
> As the disclaimer goes with EVERY post I make to the MLs here: I am not an
> expert, and I am not an active developer here. I am asking that it be
> considered, if it hasn't already, that package integration be an optional,
> if not disabled-by-default, feature. Let the admin know (with confirmation)
> that package integration is on, and that the OS will attempt to
> "inetlligently" (emphasis on quotes) adjust firewall settings based on
> installed programs.
>
> It could be argued that if someone wants full control over their firewall
> they could just use iptables, but meh.
>
> On Thu, Sep 4, 2008 at 10:58 AM, James Dinkel <[hidden email]> wrote:
> > On Thu, Sep 4, 2008 at 10:39 AM, Soren Hansen <[hidden email]> wrote:
> >> On Thu, Sep 04, 2008 at 09:58:40AM -0500, James Dinkel wrote:
> >> > I would say leave the ports open and leave the profile files.  Leave
> >> > it up to the user to manage the firewall.  If the package is removed,
> >> > it's not going to be listening on those ports any more anyway.
> >>
> >> If "not listening" was sufficient, there'd be little point in having a
> >> firewall in the first place, wouldn't there?
> >>
> >> --
> >> Soren Hansen
> >
> > Well, 'not listening' _should_ be sufficient, however I prefer (and
> > suggest) to use a firewall as an extra layer of protection.  I must have
> > been mistaken, I did not realize we were debating the merits of a
> > firewall, only whether or not packages should automatically change
> > firewall rules.  Of course, if I trusted packages to manage opening and
> > closing their own firewall rules, then I might as well trust them to
> > listen or not on those ports, so in that case then yes there would be
> > little point in having a firewall in the first place.
> >
> > James
> >
> > On Thu, Sep 4, 2008 at 10:02 AM, Cody A.W. Somerville <
> >
> > [hidden email]> wrote:
> >> Why don't we just leave all ports open then? :P
> >>
> >> --
> >> Cody A.W. Somerville <[hidden email]>
> >
> > Well, for a long time that was the standard setup for Ubuntu.  As I
> > mentioned above though, I would suggest using a firewall with all ports
> > blocked by default as an additional layer of protection.
> >
> >

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

RE: ufw package integration

Chris Martin-3
In reply to this post by Soren Hansen-2
Not listening is sufficient - that is the point
Having a firewall that is automatically updated as packages are installed is
dangerous.  This is similar to UPnP and not the right way to do security

By having all packages automatically update the firewall - you may as well
not have a firewall

Just because a HTTP server is installed it doesn't mean that it should be
accessible.  The decision to open the firewall should be a separate action

Often packages get installed that are only intended to be accessed via a
single interface on machines with multiple interfaces or via local host ONLY

It really defeats the purpose of having a firewall if the ports are opened
automatically

---------------------------------
Chris Martin
e:  [hidden email]
m: +61(0)419812371
---------------------------------
-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Soren Hansen
Sent: Friday, 5 September 2008 1:39 AM
To: [hidden email]; [hidden email];
[hidden email]
Subject: Re: ufw package integration

On Thu, Sep 04, 2008 at 09:58:40AM -0500, James Dinkel wrote:
> I would say leave the ports open and leave the profile files.  Leave
> it up to the user to manage the firewall.  If the package is removed,
> it's not going to be listening on those ports any more anyway.

If "not listening" was sufficient, there'd be little point in having a
firewall in the first place, wouldn't there?

--
Soren Hansen               |
Virtualisation specialist  | Ubuntu Server Team
Canonical Ltd.             | http://www.ubuntu.com/


--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: ufw package integration

Soren Hansen-2
On Fri, Sep 05, 2008 at 11:31:27AM +1000, Chris Martin wrote:

> Not listening is sufficient - that is the point
> Having a firewall that is automatically updated as packages are installed is
> dangerous.  This is similar to UPnP and not the right way to do security
>
> By having all packages automatically update the firewall - you may as well
> not have a firewall
>
> Just because a HTTP server is installed it doesn't mean that it should be
> accessible.  The decision to open the firewall should be a separate action
>
> Often packages get installed that are only intended to be accessed via a
> single interface on machines with multiple interfaces or via local host ONLY
>
> It really defeats the purpose of having a firewall if the ports are opened
> automatically
Unless I'm much mistaken here, all that's being discussed is *closing*
ports when you uninstall the package that "owned" the ports in question.

--
Soren Hansen               |
Virtualisation specialist  | Ubuntu Server Team
Canonical Ltd.             | http://www.ubuntu.com/

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (324 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ufw package integration

Didier Roche-2
(Sorry of top post as gmail seems to be used to it...)

On Fri, Sep 05, 2008 at 11:31:27AM +1000, Chris Martin wrote:
> Not listening is sufficient - that is the point
> Having a firewall that is automatically updated as packages are installed is
> dangerous.  This is similar to UPnP and not the right way to do security
>
> By having all packages automatically update the firewall - you may as well
> not have a firewall
>
> Just because a HTTP server is installed it doesn't mean that it should be
> accessible.  The decision to open the firewall should be a separate action
>
> Often packages get installed that are only intended to be accessed via a
> single interface on machines with multiple interfaces or via local host ONLY
>
> It really defeats the purpose of having a firewall if the ports are opened
> automatically

Hum, no. From what I understand, ufw allow different application policies for package integration. The default policy is SKIP[1], so no rules are automatically added to the firewall. You can set it so ALLOW or DENY to automatically add rules to your firewall when installing a package.

My tests when working on adding ufw integration to various packages confirmed that.


Unless I'm much mistaken here, all that's being discussed is *closing*
ports when you uninstall the package that "owned" the ports in question.


Yes, the subject has diverged. Now that the previous point is - I think - solved, let's go on the closing port question when removing/purging a package.

Didier

[1] https://wiki.ubuntu.com/UbuntuFirewall#Package%20Integration

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: ufw package integration

Nick Barcet
In reply to this post by Soren Hansen-2
Soren Hansen wrote:

> On Fri, Sep 05, 2008 at 11:31:27AM +1000, Chris Martin wrote:
>> Not listening is sufficient - that is the point
>> Having a firewall that is automatically updated as packages are installed is
>> dangerous.  This is similar to UPnP and not the right way to do security
>>
>> By having all packages automatically update the firewall - you may as well
>> not have a firewall
>>
>> Just because a HTTP server is installed it doesn't mean that it should be
>> accessible.  The decision to open the firewall should be a separate action
>>
>> Often packages get installed that are only intended to be accessed via a
>> single interface on machines with multiple interfaces or via local host ONLY
>>
>> It really defeats the purpose of having a firewall if the ports are opened
>> automatically
>
> Unless I'm much mistaken here, all that's being discussed is *closing*
> ports when you uninstall the package that "owned" the ports in question.
We were, indeed, and if I quote Jamie's original email that started this
thread:

> For example, when apache is installed, it could add a file to
> /etc/ufw/applications.d which declares it as running on tcp port 80.
> User's could then do:
> $ sudo ufw allow Apache

it seems clear that port WILL NOT be opened automatically.  It will
require the user's intervention.

Nick


--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ufw package integration

Jamie Strandboge-3
In reply to this post by Steve Langasek-6
On Wed, 03 Sep 2008, Steve Langasek wrote:

> On Tue, Aug 19, 2008 at 05:05:44PM -0400, Jamie Strandboge wrote:
> > With the upload of ufw 0.20 to Intrepid yesterday, ufw now supports
> > application (package) integration. This allows packages to declare their
> > ports and protocols to ufw, so user's can specify an application profile
> > when adding and removing rules. Application profiles can be thought of
> > as simply port/protocol groups that are referenced by name.
>
> > For example, when apache is installed, it could add a file to
> > /etc/ufw/applications.d which declares it as running on tcp port 80.
>
> If the files are installed in /etc/, then they have to be config files
> (conffiles or otherwise).  Config files are left installed when packages are
> removed, and deleted only on package purge.  How does this design prevent
> leaving ports open when the package that they legitimately correspond to is
> no longer installed?
>
This is (of course) correct. If the user decides to create a rule using
the profile, then on removal or purge the rule is not removed.
Application rules are no different than regular rules in this regard.
Eg, these are equivalent:

# ufw allow 80/tcp
# ufw allow Apache

ufw tries to not make firewall policy decisions on behalf of the user on
package installation, and does not open any ports on package install. As
such, just like opening tcp port 80 is opt in, using application profile
'Apache' is also opt in.

ufw handles the purge of an application gracefully and will still
display the rule via 'ufw status' as if the package was still installed.

Jamie

--
Ubuntu Security Engineer     | http://www.ubuntu.com/
Canonical Ltd.               | http://www.canonical.com/

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ufw package integration

Jamie Strandboge-3
In reply to this post by James Dinkel-2
On Thu, 04 Sep 2008, James Dinkel wrote:

>    I would say leave the ports open and leave the profile files.  Leave it up
>    to the user to manage the firewall.  If the package is removed, it's not
>    going to be listening on those ports any more anyway.
>

This is almost what happens. The profile files are conffiles, so they
are removed on purge. However, users can still a) see the application
rule via 'ufw status' and b) still delete the application rule by using
the profile name.

Jamie

--
Ubuntu Security Engineer     | http://www.ubuntu.com/
Canonical Ltd.               | http://www.canonical.com/

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ufw package integration

Jamie Strandboge-3
In reply to this post by Luke L
On Thu, 04 Sep 2008, Luke L wrote:

>    Should package integration be disabled by default?

There is confusion as to what 'package integration' actually does. When
I sent the email, this is what it meant:

a) a package can declare itself to ufw via profiles that have various
   port/protocol combinations
b) a user can use profile names in rules in addition to port/protocol
   combinations
c) an administrator can set the 'default application policy' to be one
   of 'skip', 'allow' or 'deny'. This affects what happens when
   'ufw app update --add-new <profile>' is run. 'skip' is the default
   and will *under no circumstances* add any rules to the firewall. Only
   if the default application policy is changed away from 'skip' will
   any rules be added
d) with the above in place, I had written a section in UbuntuFirewall which
   used 'ufw app update --add-new <profile>' in postinst, so that *if* an
   administrator decided to change the default policy to something other
   than 'skip', rules could be automatically added on installation.

However, after posting the email, I decided that using dpkg triggers was
the way to go (thanks Colin Watson!), and as such, 'update --add-new' is
no longer used in Ubuntu packaging, so it is not possible to open any
ports via package integration at this time (when functionality in dpkg
triggers is added, this may change in the future). All applications in
Ubuntu that supply application profiles take advantage of dpkg triggers.

Bottom line: 'a' and 'b' are the common use cases, and using package
integration is completely opt in.

Jamie

--
Ubuntu Security Engineer     | http://www.ubuntu.com/
Canonical Ltd.               | http://www.canonical.com/

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [ubuntu-hardened] ufw package integration

Jamie Strandboge-3
In reply to this post by Jamie Strandboge-3
On Fri, 05 Sep 2008, Jamie Strandboge wrote:

> This is (of course) correct. If the user decides to create a rule using
> the profile, then on removal or purge the rule is not removed.
> Application rules are no different than regular rules in this regard.
> Eg, these are equivalent:
>
> # ufw allow 80/tcp
> # ufw allow Apache
>
> ufw tries to not make firewall policy decisions on behalf of the user on
> package installation, and does not open any ports on package install. As
> such, just like opening tcp port 80 is opt in, using application profile
> 'Apache' is also opt in.
>
> ufw handles the purge of an application gracefully and will still
Also, the decision to *not* remove rules on package purge and/or removal
is because that would undo in packaging what an administrator had
explicitly added to his/her firewall outside of packaging. This is making
an adminstrative decision for the user that IMO ufw and it's packaging is
not equipped to make properly.

There is an argument for removing the rules if the default application
policy was changed from 'skip' *and* the packaging adds profiles via
'update --add-new'. However, this is not what is currently happening in
packaging and can be discussed if this happens at some future date (see
other email regarding this).

Jamie

--
Ubuntu Security Engineer     | http://www.ubuntu.com/
Canonical Ltd.               | http://www.canonical.com/

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (196 bytes) Download Attachment