date:20090724

On Thu, Jul 23, 2009 at 2:16 PM, Ahmed
Kamal wrote:
> Hi,
>
> Here's a RFE for FireKit, a firewall desktop "kit".

The firewall is a longstanding messy problem, and I'm glad you're
interested in tackling it.

> User Experience:
> ===
> 1- Joe wants some help from his co-worker, he shares his Gnome desktop
> through vino. Vino kicks FireKit to ask Joe if he would like to open port
> 5900, and asks for a period of time. Joe selects yes, and chooses 30
> minutes. FireKit instructs iptables to open that port, and waits for 30
> mins.

This doesn't make sense to me - if I enable user sharing, why should I
have to enable it again?

> 2- Sally wants to share last night's photos with her team. She drops the
> photos in /var/www/html, and starts apache.

There's gnome-user-share for this which would be easier out of the
box.  I don't think the desktop firewall scope should mix in support
for Unix servers, i.e. anything that traditionally listens on a port <
1024.

Backing up a minute, in discussions among the desktop team and other
people about this, one thing that came up as a specific problem with
having no firewall at all was the "public WiFi hotspot" case.  If for
example I enable desktop sharing before leaving work, then head to the
airport, and log on there to WiFi, you really don't want the desktop
sharing still enabled.  Nor likely do you want sshd.

In most of the other cases I can think of though, the firewall is
either a hindrance (trusted network at home or office), or pointless
(connected via 3G modem).

Which leads me to think that rather than being based on individual
ports and time, we just need a nice way to globally toggle the
firewall.  And that could come down to marking networks as explicitly
trusted in NetworkManager, say.

So the user experience could be a bit more like this:

1) Joe is a salesperson who is visiting another company and connected
to their public WiFi.  He wants to enable desktop sharing so people
not in the conference room can easily see his presentation.  He goes
into vino and selects sharing.  Vino sends a dbus message to
NetworkManager which says it's requesting a service.  NetworkManager
knows this network isn't yet trusted, and sends a message to nm-applet
asking whether to make the network trusted or not.  If the network
transitions from untrusted to trusted, the firewall is disabled for
the time he is connected to that network.  This is a transient state -
if Joe suspends his computer, shuts down, or connects to another
network, the firewall goes back up.

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

Re: RFE: FireKit

2009-07-24 Thread Adam Miller

On Fri, Jul 24, 2009 at 10:34 AM, Colin Walters wrote:

>
> Backing up a minute, in discussions among the desktop team and other
> people about this, one thing that came up as a specific problem with
> having no firewall at all was the "public WiFi hotspot" case.  If for
> example I enable desktop sharing before leaving work, then head to the
> airport, and log on there to WiFi, you really don't want the desktop
> sharing still enabled.  Nor likely do you want sshd.
>
> In most of the other cases I can think of though, the firewall is
> either a hindrance (trusted network at home or office), or pointless
> (connected via 3G modem).
>
> Which leads me to think that rather than being based on individual
> ports and time, we just need a nice way to globally toggle the
> firewall.  And that could come down to marking networks as explicitly
> trusted in NetworkManager, say.


Might we want to look at having "firewall profiles" such that
different sets of rules can be applied based on environment?

Also, is this planned to modify /etc/sysconfig/iptables and just
restart the service or is the plan to take a FireStarter approach and
be a substitute for /etc/sysconfig/iptables?

-Adam

-- 
http://maxamillion.googlepages.com
-
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

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

Re: RFE: FireKit

2009-07-24 Thread Michael Cronenworth

Ahmed Kamal on 07/24/2009 10:12 AM wrote:
> I agree a long running daemon would best be written in C, perhaps pyGtk
> would be good enough for only the GUI config dialogs. I will start a
> request for a fedorahosted project, then I'll work on recruiting
> developers yes.
> 

GUI? What GUI? You don't need to write a new GUI.

Create a D-BUS daemon that NetworkManager can interact with.
NetworkManager is all about managing the network and it is exactly where
firewall configuration should be.

Take notes from Colin Walters reply about needing profiles.  You could
have a firewall profile per each Wi-Fi point you connect to. nm-applet
should provide tweaking of the profile if necessary. You could have
inotify pop-ups from nm-applet when something needs firewall access (in
or out).

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

Re: RFE: FireKit

On Fri, Jul 24, 2009 at 11:39 AM, Adam Miller wrote:
>
> Might we want to look at having "firewall profiles" such that
> different sets of rules can be applied based on environment?

I'm uncomfortable to tying the solution for "desktop sharing button
doesn't actually work unless you run system-config-firewall" to a
profiles system for controlling individual ports based on network.
Maybe the toggle under the hood is a profile and system-config-network
knows about profiles, but I'm strongly against a big list of port
numbers in the default UI flow.

> Also, is this planned to modify /etc/sysconfig/iptables and just
> restart the service or is the plan to take a FireStarter approach and
> be a substitute for /etc/sysconfig/iptables?

I think that if you ever run system-config-firewall, you're a system
administrator and that tool wins, and the desktop firewall toggle
should be disabled.  How exactly that's expressed in the config system
I don't know.

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

Re: RFE: FireKit


Adam Williamson wrote:

On Thu, 2009-07-23 at 17:17 -0500, Matthew Woehlke wrote:
I have to ask... when are we going to see Linux allow network access 
based on the checksum of the process that wants to use it? After all, 
'doze has  had this ability for years. (Maybe SELinux can provide this 
already?)


It's probably a good thing we didn't do this a few years ago. With md5
checksums. ;)


Not really; checksums just provide an additional layer of security above 
the process name (or better, full path, which means root-owned are 
already pretty well protected without the checksum). Besides *any* form 
of per-process permissions would be more than we have now.


Although checksumming isn't needed if you do it via SELinux contexts in 
a way that you can't accidentally set a context, and any change to a 
binary causes the context to be dropped. (This is probably better 
because a: you rely on the OS to drop the context on /any/ change, so 
there is no checksum that can be spoofed, and b: you can trust the 
package manager to assign contexts, which results in less maintenance 
since updates via the PM don't require updating checksums.)


(And I realize that I am pretty sure SELinux doesn't provide real 
per-process security; maybe for listening, but for outbound, a good 
per-process firewall can restrict what addresses a process can talk to. 
I don't think SELinux can do this? And if it can, it is certainly 
wandering very badly into iptables' territory.)


I guess one way to do this would be to (maybe using SELinux?) toss 
sockets opened by a process (identified by full path and checksum) onto 
a specified iptables chain rather than the default OUTPUT. This would 
require the least changes to iptables, and is roughly what Tiny 
(Windows, best firewall I've encountered yet in terms of function) does.


INPUT unfortunately must be done differently since you are blocking 
above the socket layer. Besides the ability to make temporary holes 
(which I like), I think the best thing would be to have an iptables rule 
that allows stuff if there is a socket that will receive it, otherwise 
can drop (if you don't drop, you're just using 'allow' permanently and 
letting the OS handle the close notification). Then use SELinux or 
something similar to control if a process is allowed to open listen 
sockets in the first place.


--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
"unsubscribe me plz!!" -- Newbies

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

Re: openssh-blacklist - careless waste of space.

2009-07-24 Thread Daniel P. Berrange

On Fri, Jul 24, 2009 at 05:30:27PM +0300, Yanko Kaneti wrote:
> So
> 
> openssh-blacklist-0.7-1.fc11.src.rpm - size 1072930614
> http://koji.fedoraproject.org/koji/rpminfo?rpmID=1372950
> openssh-blacklist-0.7-1.fc10.src.rpm - size 1072930519
> http://koji.fedoraproject.org/koji/rpminfo?rpmID=1372948
> openssh-blacklist-0.7-1.fc12.src.rpm - size 1072930637
> http://koji.fedoraproject.org/koji/rpminfo?rpmID=1372843
> 
> ~3GB to produce 3 ~15MB rpms of copied ~20MB fingerprints.
> 
> Seriously wtf!?. And where is the frikken package review for it?

This really is insane. The source tar.gz contains

openssh-blacklist-0.7$ du -h -c -s *
4.0KCONTENT
16K COPYING
26M fingerprints
797Mprivate
358Mpublic
1.2Gtotal


The SPEC file just does

  mv fingerprints/* $RPM_BUILD_ROOT%{_datadir}/%{name}

So there is 1.2 GB of data there that is never used for any purpose
whatsoever, its not even being used to build the final data that
goes into the binary RPM.


Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

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

Re: RFE: FireKit


Stephen Gallagher wrote:

Python does not make for a particularly efficient long-running daemon.
And if your plan is to monitor for port openings in order to prompt,
it's going to need to be a long-running daemon (also you'll probably
want a kernel module component to signal your daemon when a port is opened)

If I might suggest, you probably want to use a compiled language like C.
The GLib C framework is probably a good approach, especially with its
excellent glib-dbus integration.


If I might suggest, C++ and Qt would also be a fine approach :-), the 
object model isn't built on C hacks, and Qt also has great dbus 
integration. (And it's bloody easy to design UI's in Qt. And you could 
make friends by working with KDE instead of making them play catch-up, 
for a change.) Why does everyone have to reach for glibc first?


--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
"unsubscribe me plz!!" -- Newbies

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

Re: RFE: FireKit

2009-07-24 Thread Stephen Gallagher

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/24/2009 12:03 PM, Matthew Woehlke wrote:
> Stephen Gallagher wrote:
>> Python does not make for a particularly efficient long-running daemon.
>> And if your plan is to monitor for port openings in order to prompt,
>> it's going to need to be a long-running daemon (also you'll probably
>> want a kernel module component to signal your daemon when a port is
>> opened)
>>
>> If I might suggest, you probably want to use a compiled language like C.
>> The GLib C framework is probably a good approach, especially with its
>> excellent glib-dbus integration.
> 
> If I might suggest, C++ and Qt would also be a fine approach :-), the
> object model isn't built on C hacks, and Qt also has great dbus
> integration. (And it's bloody easy to design UI's in Qt. And you could
> make friends by working with KDE instead of making them play catch-up,
> for a change.) Why does everyone have to reach for glibc first?
> 

Sorry, wasn't trying to start a holy-war. I reached for GLib mainly
because it's written in C and doesn't require pulling in the entire C++
shared object set. If we're expecting that FireKit would never be
available on a system that didn't run C++, then QT is an admirable
option as well :)

/me usually writes code intended for limited-memory/space systems, so
C++ is usually too heavyweight... but then again, so is GLib.

- -- 
Stephen Gallagher
RHCE 804006346421761

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkpp4B0ACgkQeiVVYja6o6PHBgCfeizVWzy0kk//CT3z72ZqJlWy
xnEAn3c5El4PCYeYXvGrDBUS+TyUHNFm
=0pho
-END PGP SIGNATURE-

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

Re: RFE: FireKit

Colin Walters wrote:
> If for
> example I enable desktop sharing before leaving work, then head to the
> airport, and log on there to WiFi, you really don't want the desktop
> sharing still enabled.  Nor likely do you want sshd.

 – Internal tech support, Randy Hacker speaking.
 – Hi Randy, Joe Salesman here. I'm at the airport. Something's wrong with my 
laptop. The screen just goes black when I try to start Open Office Impress. It 
worked fine yesterday. If I can't get it to work before I get to the customer's 
site I won't be able to show the presentation.
 – OK Joe, I'll SSH into your laptop and look at the logs. What's your current 
IP address?

> Which leads me to think that rather than being based on individual
> ports and time, we just need a nice way to globally toggle the
> firewall.  And that could come down to marking networks as explicitly
> trusted in NetworkManager, say.

That sounds like a really bad idea, because:

> 1) Joe is a salesperson who is visiting another company and connected
> to their public WiFi.  He wants to enable desktop sharing so people
> not in the conference room can easily see his presentation.  He goes
> into vino and selects sharing.  Vino sends a dbus message to
> NetworkManager which says it's requesting a service.  NetworkManager
> knows this network isn't yet trusted, and sends a message to nm-applet
> asking whether to make the network trusted or not.  If the network
> transitions from untrusted to trusted, the firewall is disabled for
> the time he is connected to that network.  This is a transient state -
> if Joe suspends his computer, shuts down, or connects to another
> network, the firewall goes back up.

Joe might have file sharing enabled to share his documents with his colleagues 
in his own company, but just because Joe wants to let people see the 
presentation, that doesn't mean he wants anyone who might be connected to the 
customer's network to read all his documents. Should he evaluate the 
trustworthiness of all the customer's employees as well as the security of 
their network before he starts Vino?

In one known attack against the concept of trusted networks, an attacker 
configures his laptop to present itself as a WiFi access point and broadcast a 
large number of strategically chosen SSIDs. Then he sits down in a public 
place and waits for unsuspecting laptops to recognize the SSID of their home 
network and connect automatically.

Björn Persson

signature.asc
Description: This is a digitally signed message part.
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: RFE: FireKit

2009-07-24 Thread Dan Winship

On 07/24/2009 11:34 AM, Colin Walters wrote:
> Backing up a minute, in discussions among the desktop team and other
> people about this, one thing that came up as a specific problem with
> having no firewall at all was the "public WiFi hotspot" case.  If for
> example I enable desktop sharing before leaving work, then head to the
> airport, and log on there to WiFi, you really don't want the desktop
> sharing still enabled.  Nor likely do you want sshd.
> 
> In most of the other cases I can think of though, the firewall is
> either a hindrance (trusted network at home or office), or pointless
> (connected via 3G modem).
>
> Which leads me to think that rather than being based on individual
> ports and time, we just need a nice way to globally toggle the
> firewall.  And that could come down to marking networks as explicitly
> trusted in NetworkManager, say.

Bah! If the user checks a box saying the network can be trusted then we
should use that as evidence against him. :) Firewalls are "crunchy on
the outside but chewy on the inside". How many of our users have a
not-fully-patched Windows box on their "trusted" home network? (Or even
an active malware infestation.)

And what if you and a friend are at the airport and you want to share a
file? Do you have to mark the airport wifi network trusted?

It seems like it would be better to use selinux here than a firewall.

-- Dan

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

Re: RFE: FireKit

2009/7/24 Björn Persson :
> Colin Walters wrote:
>> If for
>> example I enable desktop sharing before leaving work, then head to the
>> airport, and log on there to WiFi, you really don't want the desktop
>> sharing still enabled.  Nor likely do you want sshd.
>
>  – Internal tech support, Randy Hacker speaking.
>  – Hi Randy, Joe Salesman here. I'm at the airport. Something's wrong with my
> laptop. The screen just goes black when I try to start Open Office Impress. It
> worked fine yesterday. If I can't get it to work before I get to the 
> customer's
> site I won't be able to show the presentation.
>  – OK Joe, I'll SSH into your laptop and look at the logs. What's your current
> IP address?

In this case, when the firewall is re-enabled, it would be enabled to
whatever the system administrator has configured it to do.  In other
words if they added an explicit passthrough for port 22, that would
continue to work.

> Joe might have file sharing enabled to share his documents with his colleagues
> in his own company, but just because Joe wants to let people see the
> presentation, that doesn't mean he wants anyone who might be connected to the
> customer's network to read all his documents.

Hmm?  How would they be able to read all his documents?

> In one known attack against the concept of trusted networks, an attacker
> configures his laptop to present itself as a WiFi access point and broadcast a
> large number of strategically chosen SSIDs. Then he sits down in a public
> place and waits for unsuspecting laptops to recognize the SSID of their home
> network and connect automatically.

I believe NetworkManager's connection list is based on the pair of MAC
address + SSID, not just SSID.

Now yes, of course someone could discover the MAC and SSID of a
particular access point at a company, then when a mobile worker goes
to a coffee shop, fake being that network.  But at this point we're
getting into very targeted attacks.  And I would argue that accepting
this is a valid tradeoff versus the even more serious problem of
people who disable the firewall to get things to work and then never
re-enable it.

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

Re: RFE: FireKit

Matthew Woehlke wrote:
> an iptables rule
> that allows stuff if there is a socket that will receive it, otherwise
> can drop

Where's the point in that? To protect against possible security bugs in the 
little piece of TCP code that would otherwise reply with RST, or the little 
piece of UDP code that would just drop the packet anyway? I doubt a security 
bug in the little piece of IPtables code that drops packets is any less 
likely.

Björn Persson

signature.asc
Description: This is a digitally signed message part.
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: RFE: FireKit


Björn Persson wrote:

Matthew Woehlke wrote:

an iptables rule
that allows stuff if there is a socket that will receive it, otherwise
can drop


Where's the point in that?


Stealth? You might as well ask what is the point of using DROP (instead 
of REJECT) at all. Obviously there is a reason or else it wouldn't exist.


--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
"unsubscribe me plz!!" -- Newbies

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

Re: RFE: FireKit

On Fri, Jul 24, 2009 at 1:35 PM, Colin Walters wrote:
>
>> Joe might have file sharing enabled to share his documents with his 
>> colleagues
>> in his own company, but just because Joe wants to let people see the
>> presentation, that doesn't mean he wants anyone who might be connected to the
>> customer's network to read all his documents.
>
> Hmm?  How would they be able to read all his documents?

Oh, I see what you're saying; if they enabled gnome-user-share to
share documents at their main office.  Hmm, yes.

Ok, how about this - gnome-user-share and vino are by default tied to
networks, rather than global.  So instead of one global GConf key,
they have per-network state stored either in /system/networking or
based of some key in their own config.  When the network changes, they
adjust.

If we do ship a firewall on by default, then yes we would need a way
for these desktop apps to poke holes programatically.  Which is kind
of a mess...if Lennart wouldn't object too much maybe the code could
live inside Avahi, since most of the things we want to enable are
Avahi services.

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

Re: RFE: FireKit


Stephen Gallagher wrote:

On 07/24/2009 12:03 PM, Matthew Woehlke wrote:

Stephen Gallagher wrote:

Python does not make for a particularly efficient long-running daemon.
And if your plan is to monitor for port openings in order to prompt,
it's going to need to be a long-running daemon (also you'll probably
want a kernel module component to signal your daemon when a port is
opened)

If I might suggest, you probably want to use a compiled language like C.
The GLib C framework is probably a good approach, especially with its
excellent glib-dbus integration.

If I might suggest, C++ and Qt would also be a fine approach :-), the
object model isn't built on C hacks, and Qt also has great dbus
integration. (And it's bloody easy to design UI's in Qt. And you could
make friends by working with KDE instead of making them play catch-up,
for a change.) Why does everyone have to reach for glibc first?


Sorry, wasn't trying to start a holy-war.


:-)

Since I also do not wish to start a holy war, I'll stop now. Both camps 
have now been suggested, that is enough for me.



I reached for GLib mainly because it's written in C and doesn't
require pulling in the entire C++ shared object set.


TBH I have (almost) no experience with glib, but the mere idea of trying 
to write OO in C scares me ;-). (Conversely I have pretty decent 
experience with Qt, and absolutely love it.) C++ was designed for OO; 
"little" things like ctors/dtors make life s much easier.


--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
"unsubscribe me plz!!" -- Newbies

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

Re: RFE: FireKit

Colin Walters wrote:
> 2009/7/24 Björn Persson :
> > Colin Walters wrote:
> >> If for
> >> example I enable desktop sharing before leaving work, then head to the
> >> airport, and log on there to WiFi, you really don't want the desktop
> >> sharing still enabled.  Nor likely do you want sshd.
> >
> >  – Internal tech support, Randy Hacker speaking.
> >  – Hi Randy, Joe Salesman here. I'm at the airport. Something's wrong
> > with my laptop. The screen just goes black when I try to start Open
> > Office Impress. It worked fine yesterday. If I can't get it to work
> > before I get to the customer's site I won't be able to show the
> > presentation.
> >  – OK Joe, I'll SSH into your laptop and look at the logs. What's your
> > current IP address?
>
> In this case, when the firewall is re-enabled, it would be enabled to
> whatever the system administrator has configured it to do.  In other
> words if they added an explicit passthrough for port 22, that would
> continue to work.

Fair enough. Just don't assume that nobody would want SSH at an airport.

> > Joe might have file sharing enabled to share his documents with his
> > colleagues in his own company, but just because Joe wants to let people
> > see the presentation, that doesn't mean he wants anyone who might be
> > connected to the customer's network to read all his documents.
>
> Hmm?  How would they be able to read all his documents?

Isn't that one thing that the so called firewall is supposed to prevent? Surely 
Vino isn't the only thing you want to block when the network is considered 
untrusted?

> > In one known attack against the concept of trusted networks, an attacker
> > configures his laptop to present itself as a WiFi access point and
> > broadcast a large number of strategically chosen SSIDs. Then he sits down
> > in a public place and waits for unsuspecting laptops to recognize the
> > SSID of their home network and connect automatically.
>
> I believe NetworkManager's connection list is based on the pair of MAC
> address + SSID, not just SSID.

So in a large building with many access points you have to add each access 
point to the connection list individually?

The attack I read about was of course primarily targeted at Windows. Perhaps 
Windows looks only at the SSID. Still, I wonder how long it would take to loop 
through the MAC address ranges of all the big manufacturers of access points.

Björn Persson



signature.asc
Description: This is a digitally signed message part.
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: RFE: FireKit

Colin Walters wrote:
> Ok, how about this - gnome-user-share and vino are by default tied to
> networks, rather than global.  So instead of one global GConf key,
> they have per-network state stored either in /system/networking or
> based of some key in their own config.  When the network changes, they
> adjust.

If each service would have its own independent per-network state, then yes, 
that's better. Not as a replacement for strong authentication and access 
control, but as a complement.

> If we do ship a firewall on by default, then yes we would need a way
> for these desktop apps to poke holes programatically.

Personally I would prefer not shipping insecure services by default, so that 
no "firewall" is needed.

Björn Persson

signature.asc
Description: This is a digitally signed message part.
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: RFE: FireKit

Matthew Woehlke wrote:
> Björn Persson wrote:
> > Matthew Woehlke wrote:
> >> an iptables rule
> >> that allows stuff if there is a socket that will receive it, otherwise
> >> can drop
> >
> > Where's the point in that?
>
> Stealth? You might as well ask what is the point of using DROP (instead
> of REJECT) at all. Obviously there is a reason or else it wouldn't exist.

That's obscurity, not security. If there's a hole in Sendmail for example, 
then attackers trying to exploit that hole won't start by probing port 26384 
and then connect to port 25 only if they get an RST packet from port 26384. 
They'll go straight on port 25. You're not truly "stealth" unless you drop 
*all* packets, at which point you can just as well unplug the network cable 
(or turn WiFi off with the kill switch).

My personal packet filter drops disallowed packets if either address is a 
multicast or broadcast address. If both addresses are unicast addresses it 
rejects the packet with the "administratively prohibited" code. This makes 
troubleshooting a whole lot easier than if the packets just disappear.

Björn Persson

signature.asc
Description: This is a digitally signed message part.
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: RFE: FireKit

On 07/24/2009 02:09 AM, Aioanei Rares wrote:
> I tend to agree here. Maybe C++ would be a far better option (biased, of
> course :)
> 

Ugh. I think C will do just fine. Its perfectly adequate without growing any 
tumorous appendages.

/me waits patiently for Objective C on linux to be worth a damn.

--CJD

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

Re: RFE: FireKit


Björn Persson wrote:

Matthew Woehlke wrote:

Björn Persson wrote:

Matthew Woehlke wrote:

an iptables rule
that allows stuff if there is a socket that will receive it, otherwise
can drop

Where's the point in that?

Stealth? You might as well ask what is the point of using DROP (instead
of REJECT) at all. Obviously there is a reason or else it wouldn't exist.


That's obscurity, not security.


Why is it people seem to have a problem with obscurity *on top of* 
security? What's wrong with making it as hard as possible for the "bad 
guys"?


If there's a hole in Sendmail for example, 
then attackers trying to exploit that hole won't start by probing port 26384 
and then connect to port 25 only if they get an RST packet from port 26384.


...and if I happen to not be running sendmail at the time, my machine 
will appear to not exist, rather than going on the 'try other exploits' 
list. (Especially if I happen to be not running /any/ services at the 
time and am therefore truly stealthy.)


You're not truly "stealth" unless you drop *all* packets, at which 
point you can just as well unplug the network cable (or turn WiFi off

with the kill switch).


Not all packets, just incoming ones that don't belong to established 
connections. (I'll assume we're not talking about a black hat to whose 
server you have explicitly connected.)


Besides, you didn't address the original question: if DROP is as 
non-useful as you claim, why does it exist?


--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
"unsubscribe me plz!!" -- Newbies

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

Re: RFE: FireKit


Casey Dahlin wrote:

On 07/24/2009 02:09 AM, Aioanei Rares wrote:

I tend to agree here. Maybe C++ would be a far better option (biased, of
course :)


Ugh. I think C will do just fine. Its perfectly adequate without growing any 
tumorous appendages.


C is just fine for device drivers, just don't make me write a GUI using 
only C ;-). ("Tumorous appendage"? I object to that...)


--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
"unsubscribe me plz!!" -- Newbies

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

FESCo meeting summary for 2009-07-24

2009-07-24 Thread Jon Stanley

Here is the summary and logs from today's FESCo meeting.

Minutes:
http://meetbot.fedoraproject.org/fedora-meeting/2009-07-24/fedora-meeting.2009-07-24-16.59.html
Minutes (text):
http://meetbot.fedoraproject.org/fedora-meeting/2009-07-24/fedora-meeting.2009-07-24-16.59.txt
Log:
http://meetbot.fedoraproject.org/fedora-meeting/2009-07-24/fedora-meeting.2009-07-24-16.59.log.html

16:59:51 #startmeeting FESCo meeting - 2009-07-24
16:59:55 * notting nominates zodbot for FESCo
16:59:56 #chair dgilmore jwb notting nirik sharkcz jds2001
j-rod skvidal Kevin_Kofler
17:00:02 FESCo meeting ping -- dgilmore, jwb, notting,
nirik, sharkcz, jds2001, j-rod, skvidal, Kevin_Kofler
17:00:07 * notting is here
17:00:08 * Kevin_Kofler is here.
17:00:09 * nirik is here.
17:00:09 * sharkcz is here
17:00:17 * ricky watches from afar
17:01:01 so f13 needs to get some eyedrops
17:01:07 so i told him i'd start with him
17:01:18 #topic No frozen rawhide proposal
17:01:22 .fesco 224
17:01:25 * jwb is here
17:01:41 * nirik goes to look over the page again
17:01:51 * skvidal is here
17:02:20 * dgilmore is here but needs to leave in 30 minutes
17:02:27 * j-rod in and out for a sec...
17:02:59 f13: so, bits go to 12/Everything at branch time. Is
that installable then?
17:03:08 yes
17:03:29 it will hopefully remain installable :)
17:03:31 I'm here now
17:03:39 +1 to the proposal.
17:03:47 yes, we wouldn't attempt to make rawhide the path installable
17:03:59 we'd only start making it installable each night once
we branch and start publishing it in a different path
17:04:15 we will still do installable trees and installable live
images when requested for test days
17:04:25 when the anaconda team feels that it's ready to have
wider audience testing of it
17:04:55 so if one wants to install rawhide, they'll need to
run pungi themselves?
17:05:04 so this may result in more people getting on the f12
train before f12 is out, but I don't think thats a bad thing... as
long as there are not too many blowups at the end of the cycle.
17:05:08 Oh, no install images for devel? I don't see
that written down in the proposal.
17:05:12 i.e. pungify won't run on the tree?
17:05:13 And I don't think I like that.
17:05:28 I don't see the benefit of dropping them.
17:05:43 They don't always work, but sometimes working
is better than nothing.
17:05:49 less splintering of testers
17:06:04 Kevin_Kofler: you can build the images yourself if needed.
17:06:09 to get to rawhide, you would install the last snapshot,
or the last release, and then yum update to rawhide
17:06:26 because constantly getting bugs about installer not
working, when the installer isn't ready for testing, is not really
helpful
17:06:46 there are other ways to deal with that, but sure
17:07:02 I'm not 100% wedded to this particular wrinkle though.
17:07:07 jwb: what other ways?
17:07:26 jds2001, don't build anaconda packages that aren't
considered usable for testing to begin with
17:08:22 Indeed. All the other packages only push
versions which are supposed to be actually testable to Rawhide.
17:08:35 that aside, i think not having rawhide installable at
that point helps focus testing efforts. so i'm ok with it
17:08:37 Why should Anaconda be special?
17:08:59 lots of very broken packages wind up in rawhide
17:09:03 anaconda isn't special there.
17:09:07 jds2001, Kevin_Kofler, that's a tangent that we can
focus on later. we have a big agenda...
17:09:10 * nirik looks, so when is the mass branch?
17:09:18 nirik: at alpha freeze
17:09:34 so if we enact it for F12, in about 2 weeks
17:09:38 wow... so pretty early.
17:09:43 yes
17:09:55 to drive home the point that after Alpha, the focus
should be on bugfix
17:10:02 new fancy development can happen in rawhide
17:10:07 which will be published
17:10:11 and useful for f13 goals
17:10:20 so composing both a 12/Everything and a development
won't be a problem resource wise?
17:10:28 this fixes a lot of issues :)
17:10:31 s/f13/F13
17:10:33 * j-rod has read over the proposal in detail, hashed out
stuff on the list, etc...
17:10:36 nirik: it's going to hurt, but we're making inroads on that.
17:10:39 +1 for this, I like it a lot
17:11:03 And the mass branch is also when install
images start being built daily?
17:11:04 +1, I like it too
17:11:11 Kevin_Kofler: yes
17:11:12 I think it's worth trying, and has a lot of advantages. +1
17:11:18 +1 it seems to make sense to try
17:11:20 mash is now considerably faster if I've been
reading correctly.
17:11:21 f13, are we confident we can get the bodhi and mash
changes in place in 2 weeks?
17:11:26 Kevin_Kofler: ideally we'd have had a few installer
test days prior to feature freeze
17:11:30 jds2001, not exactly, no
17:11:36 jwb: luke said it should be minimal effort.
17:11:39 jwb: :(
17:11:47 jds2001: it was faster until we turned on deltas
17:12:03 clear
17:12:09 jwb: I'd like to set a timeline that if we're not ready
by alpha freeze, we punt to f

Re: RFE: FireKit

2009-07-24 Thread Bill McGonigle

On 07/23/2009 06:17 PM, Matthew Woehlke wrote:
> I have to ask... when are we going to see Linux allow network access
> based on the checksum of the process that wants to use it? After all,
> 'doze has  had this ability for years. (Maybe SELinux can provide this
> already?)

Is this a checksum of the binary that got launched?  Make sure prelink
can update whatever database of checksums is being kept.  And that
prelink isn't exploitable. :)

This can't be a default on MSW, right?  My spam filter's pain would seem
to deny that possibility.

-Bill

-- 
Bill McGonigle, Owner   Work: 603.448.4440
BFC Computing, LLC  Home: 603.448.1668
http://www.bfccomputing.com/Cell: 603.252.2606
Twitter, etc.: bill_mcgonigle   Page: 603.442.1833
Email, IM, VOIP: b...@bfccomputing.com
Blog: http://blog.bfccomputing.com/
VCard: http://bfccomputing.com/vcard/bill.vcf

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

Firewall rules using SELinux context (Was Re: RFE: FireKit)

A couple of mentions of SELinux have cropped up in the FireKit thread, which 
got me thinking about the Firewall and SELinux and ways in which they are 
similar. I had the following thought:

SELinux already has a lot of policy information from which we might like to 
determine whether ports should be open to a particular program. The simplest 
mechanism I can see for doing that is to allow SELinux context to be referenced 
in the firewall rules. This prevents either system from having to be 
grotesquely modified.

An example rule might look like this:

-A INPUT -Z apache_t -j ACCEPT

Here we tell the firewall to allow incoming traffic that will be intercepted in 
userspace by a process in the apache_t context.

This does break in at least one way from traditional SELinux policy: something 
external to SELinux is interpreting the meaning of the context. The firewall 
rules can change while the actual SELinux policy stays put. I don't know how 
serious a problem that is (if it is one).

Thoughts?

--CJD

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

Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)

2009-07-24 Thread Stephen Smalley

On Fri, 2009-07-24 at 15:47 -0400, Casey Dahlin wrote:
> A couple of mentions of SELinux have cropped up in the FireKit thread, which 
> got me thinking about the Firewall and SELinux and ways in which they are 
> similar. I had the following thought:
> 
> SELinux already has a lot of policy information from which we might like to 
> determine whether ports should be open to a particular program. The simplest 
> mechanism I can see for doing that is to allow SELinux context to be 
> referenced in the firewall rules. This prevents either system from having to 
> be grotesquely modified.
> 
> An example rule might look like this:
> 
> -A INPUT -Z apache_t -j ACCEPT
> 
> Here we tell the firewall to allow incoming traffic that will be intercepted 
> in userspace by a process in the apache_t context.
> 
> This does break in at least one way from traditional SELinux policy: 
> something external to SELinux is interpreting the meaning of the context. The 
> firewall rules can change while the actual SELinux policy stays put. I don't 
> know how serious a problem that is (if it is one).
> 
> Thoughts?

SECMARK already allows you to label packets using iptables and then use
SELinux policy to control sending or receiving them.

http://paulmoore.livejournal.com/4281.html

There are also the name_connect and name_bind controls that regulate the
ability to connect or bind to specific ports via policy.

-- 
Stephen Smalley
National Security Agency

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

Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)

On 07/24/2009 03:53 PM, Stephen Smalley wrote:
> On Fri, 2009-07-24 at 15:47 -0400, Casey Dahlin wrote:
>> A couple of mentions of SELinux have cropped up in the FireKit thread, which 
>> got me thinking about the Firewall and SELinux and ways in which they are 
>> similar. I had the following thought:
>>
>> SELinux already has a lot of policy information from which we might like to 
>> determine whether ports should be open to a particular program. The simplest 
>> mechanism I can see for doing that is to allow SELinux context to be 
>> referenced in the firewall rules. This prevents either system from having to 
>> be grotesquely modified.
>>
>> An example rule might look like this:
>>
>> -A INPUT -Z apache_t -j ACCEPT
>>
>> Here we tell the firewall to allow incoming traffic that will be intercepted 
>> in userspace by a process in the apache_t context.
>>
>> This does break in at least one way from traditional SELinux policy: 
>> something external to SELinux is interpreting the meaning of the context. 
>> The firewall rules can change while the actual SELinux policy stays put. I 
>> don't know how serious a problem that is (if it is one).
>>
>> Thoughts?
> 
> SECMARK already allows you to label packets using iptables and then use
> SELinux policy to control sending or receiving them.
> 
> http://paulmoore.livejournal.com/4281.html
> 
> There are also the name_connect and name_bind controls that regulate the
> ability to connect or bind to specific ports via policy.
> 

This is a very different mechanism. The idea behind my proposal is it allows a 
packet to be routed based on who is going to receive it. SECMARK, it seems, is 
designed to control who receives a packet based on how it is being routed. I 
don't know if you get the same effect this way.

--CJD

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

Re: RFE: FireKit

2009-07-24 Thread Bill McGonigle

On 07/24/2009 03:21 PM, Matthew Woehlke wrote:
> Why is it people seem to have a problem with obscurity *on top of*
> security? What's wrong with making it as hard as possible for the "bad
> guys"?

It's well known that "security through obscurity" is an insufficient
defense.  Only fools would rely on obscurity for strong security.  Some
have taken that to mean that only fools employ obscurity as part of
their security.

In nearly all cases that anybody here will be asked to deal with,
attackers have more than one potential target and will take the
lowest-cost path to achieve their ends.  Obscurity increases costs.

Getting a strong safe with a good lock is important if you're going to
keep your gold in your house.  Burying that safe in the back yard or
behind a wall increases the amount of time it will take a good
safe-cracker to get your gold, by varying amounts.  He's only got so
much time since your alarm system already called the cops, so if you
make him spend that time finding the safe, he has less time to crack it.

But the costs aren't only for the safe cracker.  If you've buried that
safe in the back yard, it's going to be a bitch to get the gold out when
you need it.  Same with DROP'ing packets - it makes network management
and troubleshooting harder.  So, more people will opt for a hidden
wall-mounted safe and not put a sign on their front door that reads,
"the safe is under bar in the study".  Even if it's got an awesome lock.

I use layered firewalls, encrypt my disks, keep my software up-to-date,
REJECT connections, respond to pings, and I'm not telling you where my
gold is hidden. ;)  Those are the right trade-offs for my situation, YMMV.

-Bill

-- 
Bill McGonigle, Owner   Work: 603.448.4440
BFC Computing, LLC  Home: 603.448.1668
http://www.bfccomputing.com/Cell: 603.252.2606
Twitter, etc.: bill_mcgonigle   Page: 603.442.1833
Email, IM, VOIP: b...@bfccomputing.com
Blog: http://blog.bfccomputing.com/
VCard: http://bfccomputing.com/vcard/bill.vcf

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

Re: RFE: FireKit


Bill McGonigle wrote:

On 07/23/2009 06:17 PM, Matthew Woehlke wrote:

I have to ask... when are we going to see Linux allow network access
based on the checksum of the process that wants to use it? After all,
'doze has  had this ability for years. (Maybe SELinux can provide this
already?)


Is this a checksum of the binary that got launched?  Make sure prelink
can update whatever database of checksums is being kept.  And that
prelink isn't exploitable. :)


True. For us, something based on SELinux contexts, which should be 
dropped by the kernel on any modification (and allowed to be set by 
trusted components, say prelink and yum/rpm) is probably as good or 
better than using checksums. (Which still requires prelink to be secure, 
but then that's already required, as rogue prelink could be wreaking 
who-knows-what havoc...)



This can't be a default on MSW, right?  My spam filter's pain would seem
to deny that possibility.


It's not built into MSW if that's what you mean. It's from Tiny, which I 
used before switching totally to Fedora. By "has this ability" I mean 
that FW's for MSW exist which have this feature. (Also, Tiny is *not* a 
firewall for people that don't know what they are doing; using Tiny is, 
I would say, on par with 'vi /etc/sysconfig/iptables' in terms of 
user-friendliness. Powerful, really not bad when you know what you are 
doing, but absolutely not for 'Joe Sixpack'.)


--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
"unsubscribe me plz!!" -- Newbies

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

F12 Alpha Blocker Bug review meeting recap 2009-07-24

2009-07-24 Thread James Laska

Greetings folks,

A quick recap of today's blocker bug review meeting for Fedora 12 Alpha.
Full irc transcript available at
http://meetbot.fedoraproject.org/fedora-bugzappers/2009-07-24/fedora-bugzappers.2009-07-24-15.03.html.

= Attendees =

adamw, jlaska, f13, notting, bugbot (can't forget him), denise, alindebe

= Blocker lists reviewed =

  * F12Alpha -

https://bugzilla.redhat.com/showdependencytree.cgi?id=F12Alpha&hide_resolved=1
  * F12Beta -

https://bugzilla.redhat.com/showdependencytree.cgi?id=F12Beta&hide_resolved=1
  * F12Blocker -

https://bugzilla.redhat.com/showdependencytree.cgi?id=F12Blocker&hide_resolved=1

= Action items =

 1. jlaska - check for any F12 install test case updates related
to /boot as ext4
 2. adamw poke S.A. Hartsuiker re #498156
 3. jlaska talk to dlehman about #512651 and F12 storage cleanup

= Next meeting =

Friday, July 31 at 15:00 UTC (11:00 AM EDT).

= Want to help? =

Join an upcoming blocker bug meeting and help assess impact of escalated
issues.  Alternatively, feed us bugs.  Mark an issue you feel should be
considered for the Alpha, Beta or final release by setting Blocks:
F12Alpha, F12Beta, or F12Blocker respectively.

Thanks,
James


signature.asc
Description: This is a digitally signed message part
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)

'Content-Type: format=flowed' would be really nice, as opposed to the 
'one line per paragraph' you sent...


Casey Dahlin wrote:
A couple of mentions of SELinux have cropped up in the FireKit 
thread, which got me thinking about the Firewall and SELinux and ways

in which they are similar. I had the following thought:

SELinux already has a lot of policy information from which we might 
like to determine whether ports should be open to a particular

program. The simplest mechanism I can see for doing that is to allow
SELinux context to be referenced in the firewall rules. This prevents
either system from having to be grotesquely modified.

An example rule might look like this:

-A INPUT -Z apache_t -j ACCEPT

Here we tell the firewall to allow incoming traffic that will be
intercepted in userspace by a process in the apache_t context.


My question is, can this even work? There is a reason I suggested that 
on the /INPUT/ side, iptables have no more smarts than 'is there a 
socket that will accept this packet'. (Then use SELinux to allow/prevent 
those sockets from being opened in the first place.)


I like the idea for the OUTPUT chain, however.

This does break in at least one way from traditional SELinux policy: 
something external to SELinux is interpreting the meaning of the 
context. The firewall rules can change while the actual SELinux

policy stays put. I don't know how serious a problem that is (if it
is one).


I think this makes sense. You may want the rules for $DAEMON to change 
based on network connectivity, or even intangible parameters (e.g. "I 
just called IT and they asked for ssh access, I want to enable it but 
only for the next five minutes"). This seems easier to express in 
iptables than changing the SELinux context to cope with such events. 
Especially since the SELinux context in this case really becomes more of 
a tag than a rule set; the user determines the rules.


That said, I'm not familiar with SECMARK, so it's hard to say if it can 
accomplish the same things. (It does, however, seem to be backwards 
w.r.t. how you want rules to be defined. Can I use SECMARK to e.g. allow 
Konqueror to browse YouTube, but block Firefox?)


--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
"unsubscribe me plz!!" -- Newbies

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

Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)

2009-07-24 Thread Roland McGrath

It sounds like something that looks at an SELinux policy's rules for SECMARK
and generates corresponding iptables rules would amount to the same thing
you have in mind.  Since you load new SELinux policy in a big static-switch
sort of way, it doesn't seem much different in a way you could discern whether
you actually have the firewall driven off the AVC stuff "dynamically" or if
you just "statically" generate a set of firewall rules based on SELinux policy.

I suppose you could just integrate this into iptables userland so that the
"-Z" syntax you suggested would just look up current SELinux policy for
everything with that label and generate corresponding rules, though you
might want those rules marked somehow so that that a policy reload
automagically regenerated them.  OTOH, it seems fine enough to me to just
leave that in scriptland, so "service iptables reload" recomputes from the
current SELinux policy, and maybe the normal ways to install a policy change
do that automatically.

Perhaps the difference is that you have the firewall ports open even when
nothing running has those ports bound.  Actually, I'm not sure if that
wouldn't have been true with what you suggested anyway.  A lax SELinux
policy might be allowing anyone to bind to the SECMARK labels for those
ports, not just the daemon you have in mind.  (i.e. the targeted policy
uses SECMARK to constrain that daemon to binding only those particular
ports, but doesn't prevent random unconstrained_t processes from binding
them.)


Thanks,
Roland

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

Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)

2009-07-24 Thread Steve Grubb

On Friday 24 July 2009 03:47:51 pm Casey Dahlin wrote:
> A couple of mentions of SELinux have cropped up in the FireKit thread,
> which got me thinking about the Firewall and SELinux and ways in which they
> are similar. I had the following thought:
>
> SELinux already has a lot of policy information from which we might like to
> determine whether ports should be open to a particular program.

Just because selinux has policy doesn't mean the app is installed.

> The simplest mechanism I can see for doing that is to allow SELinux context
> to be referenced in the firewall rules. This prevents either system from
> having to be grotesquely modified.
>
> An example rule might look like this:
>
> -A INPUT -Z apache_t -j ACCEPT
>
> Here we tell the firewall to allow incoming traffic that will be
> intercepted in userspace by a process in the apache_t context.

I don't like this. Its not tying to any port. For example, suppose there is a 
vulnerability in cups and apache is not running, the cups app could start 
listening on other ports and the rule would allow connections.

> This does break in at least one way from traditional SELinux policy:
> something external to SELinux is interpreting the meaning of the context.

The kernel should always decide. Since this is a security mechanism that would 
be part of our Common Criteria work it would have to play by the rules. If its 
doing security enforcement, it will need to log AVCs.

I would recommend leaving IPTables as is. Its working great at what its 
designed to do.

-Steve

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

Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)

On 07/24/2009 04:44 PM, Steve Grubb wrote:
> On Friday 24 July 2009 03:47:51 pm Casey Dahlin wrote:
>> A couple of mentions of SELinux have cropped up in the FireKit thread,
>> which got me thinking about the Firewall and SELinux and ways in which they
>> are similar. I had the following thought:
>>
>> SELinux already has a lot of policy information from which we might like to
>> determine whether ports should be open to a particular program.
> 
> Just because selinux has policy doesn't mean the app is installed.
> 

If the app is not installed nothing is running in its context, so none of the 
rules will ever trigger.

> 
>> The simplest mechanism I can see for doing that is to allow SELinux context
>> to be referenced in the firewall rules. This prevents either system from
>> having to be grotesquely modified.
>>
>> An example rule might look like this:
>>
>> -A INPUT -Z apache_t -j ACCEPT
>>
>> Here we tell the firewall to allow incoming traffic that will be
>> intercepted in userspace by a process in the apache_t context.
> 
> I don't like this. Its not tying to any port. For example, suppose there is a 
> vulnerability in cups and apache is not running, the cups app could start 
> listening on other ports and the rule would allow connections.
> 

Only if cups were running in the apache_t context.

You seem to not quite be getting what I'm saying. What is it you expect that 
rule /does/ accomplish if not prevent the situation you describe?

--CJD

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

Re: RFE: FireKit

2009-07-24 Thread Steve Grubb

On Thursday 23 July 2009 02:16:10 pm Ahmed Kamal wrote:
> Here's a RFE for FireKit, a firewall desktop "kit". What this does is:
> 1- Exposes a dbus interface for applications to programatically open/close
> ports

I don't exactly like this. If one application gets compromised, it can now 
open other ports that may be protected. Previously, it would require 
CAP_NET_ADMIN or some other root possessed capability to make changes. There 
are a lot of important services above 1024 that a normal user could bind to. 
You don't want the system to suddenly open those ports and allow traffic.

> 2- Monitors as new daemons/applications that listen on non lo interfaces
> are started, checks if iptables is currently blocking them, and if so,
> warns the user that application X is currently blocked by the firewall

This part I like.

-Steve

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

Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)

2009-07-24 Thread Steve Grubb

On Friday 24 July 2009 04:56:51 pm Casey Dahlin wrote:
> > Just because selinux has policy doesn't mean the app is installed.
>
> If the app is not installed nothing is running in its context, so none of
> the rules will ever trigger.

If the attacker can work out the chain of allowed transitions, they can enter 
that context.


> >> The simplest mechanism I can see for doing that is to allow SELinux
> >> context to be referenced in the firewall rules. This prevents either
> >> system from having to be grotesquely modified.
> >>
> >> An example rule might look like this:
> >>
> >> -A INPUT -Z apache_t -j ACCEPT
> >>
> >> Here we tell the firewall to allow incoming traffic that will be
> >> intercepted in userspace by a process in the apache_t context.
> >
> > I don't like this. Its not tying to any port. For example, suppose there
> > is a vulnerability in cups and apache is not running, the cups app could
> > start listening on other ports and the rule would allow connections.
>
> Only if cups were running in the apache_t context.

I don't think I explained it well. I was thinking what if you had this rule:

-A INPUT -Z cups_t -j ACCEPT

and then cups was compromised and started listening on port 80. Since the 
above rule has no port restrictions and cups is allowed to accept connections, 
would cups now be able to start serving web pages?

-Steve

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

Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)

2009-07-24 Thread Roland McGrath

> I don't think I explained it well. I was thinking what if you had this rule:
> 
> -A INPUT -Z cups_t -j ACCEPT
> 
> and then cups was compromised and started listening on port 80. Since the 
> above rule has no port restrictions and cups is allowed to accept 
> connections, 
> would cups now be able to start serving web pages?

I think the idea was that cups_t is a key into policy so that policy
expresses what this iptables rule means, not that the rule says "treat
whatever any cups_t process happens to be doing this way".

At least, that's the good idea. ;-)


Thanks,
Roland

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

Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)

2009-07-24 Thread Bruno Wolff III

On Fri, Jul 24, 2009 at 16:55:23 -0400,
  Steve Grubb  wrote:
> 
> I don't think I explained it well. I was thinking what if you had this rule:
> 
> -A INPUT -Z cups_t -j ACCEPT
> 
> and then cups was compromised and started listening on port 80. Since the 
> above rule has no port restrictions and cups is allowed to accept 
> connections, 
> would cups now be able to start serving web pages?

I thought the idea was to label packets based on source and destination
(including ports) not application. Applications would get access to the
packets based on their context and the context (labels) of the packets.
I may have misunderstood though.

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

Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)

2009-07-24 Thread Simo Sorce

On Fri, 2009-07-24 at 14:00 -0700, Roland McGrath wrote:
> > I don't think I explained it well. I was thinking what if you had this rule:
> > 
> > -A INPUT -Z cups_t -j ACCEPT
> > 
> > and then cups was compromised and started listening on port 80. Since the 
> > above rule has no port restrictions and cups is allowed to accept 
> > connections, 
> > would cups now be able to start serving web pages?
> 
> I think the idea was that cups_t is a key into policy so that policy
> expresses what this iptables rule means, not that the rule says "treat
> whatever any cups_t process happens to be doing this way".
> 
> At least, that's the good idea. ;-)

from an iptables admin pov it would make more sense IMHO to have one of
the following scenarios (not sure any of them would be "right" though):

A)
A table per context.

iptables -A INPUT -Z -j SELINUX_cups_t

then SELINUX_cups_t would be a special table that is read only and
expresses the selinux policy for cups_t

you could do iptables -L -v SELINUX_cups_t and get the list of ports
allowed in this table.

A.1)
You can have a single table that list all input/output rules
iptables -A INPUT -Z -j SELINUX_cups_t
iptables -A OUTPUT -Z -j SELINUX_cups_t

A.2)
have 2 different tables:
iptables -A INPUT -Z -j SELINUX_INPUT_cups_t
iptables -A OUTPUT -Z -j SELINUX_OUTPUT_cups_t

This syntax would be easy to use but it could become extremely verbose.

B)
Another option could be that you have instead only one rule in the main
INPUT/OUTPUT tables: iptables -A INPUT -j SELINUX

And in the SELINUX table (read only) list all the contexts rules, with
-Z cups_t or -Z apache_t in ipatable -L -v -t SELINUX advertizing what
context these rules applies to.

This table may end up being quite long.

Read/Write access to SELinux tables would be equivalent to modification
of policy on the fly which would be at odd with the way SELinux is
thought out IMO.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

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

Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)

2009-07-24 Thread Simo Sorce

On Fri, 2009-07-24 at 16:21 -0500, Bruno Wolff III wrote:
> I thought the idea was to label packets based on source and
> destination
> (including ports) not application. Applications would get access to
> the
> packets based on their context and the context (labels) of the
> packets.
> I may have misunderstood though.

What's the value of labeling packets based on source/destination ports ?
Doesn't seem to add any new information.

If I get a packet for port 8080 it's always going to whatever
application is listen on port 8080, unless you label the packet with an
application context SElinux does not have any more information.

now if you allow to apply application labels to packets then you could
say that packets directed to 8080 are labeled squid_t and not apache_t
and that would make quite a difference.

It would prevent a rogue apache that gets to listen to 8080 to get any
packet as they would be labeled squid_t which is not apache_t.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

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

Re: FESCo meeting summary for 2009-07-24

2009-07-24 Thread Till Maas

On Fri July 24 2009, Jon Stanley wrote:
> Log:
> http://meetbot.fedoraproject.org/fedora-meeting/2009-07-24/fedora-meeting.2
>009-07-24-16.59.log.html

> 17:01:18  #topic No frozen rawhide proposal
> 17:01:22  .fesco 224
> 17:01:25 * jwb is here
> 17:01:41 * nirik goes to look over the page again
> 17:01:51 * skvidal is here
> 17:02:20 * dgilmore is here but needs to leave in 30 minutes
> 17:02:27 * j-rod in and out for a sec...
> 17:02:59  f13: so, bits go to 12/Everything at branch time. Is

The log seems to be incomplete, e.g. after the .fesco 224 line, there should 
probably be some line by zodbot(?) that presents a URL to the ticket or some 
other information about it.

Regards
Till


signature.asc
Description: This is a digitally signed message part.
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)

2009-07-24 Thread Roland McGrath

So I think most of us in this discussion probably don't actually understand
SECMARK.  I sure didn't.  I think I might now, sort of.  The SELinux policy
just says contexts, and it doesn't say anything about the port numbers.
The point of SECMARK is that you write port-matching rules that are what
sets the context on those packets.  You have to write those rules by hand
(or somehow) or else there just aren't ever any packets anywhere that are
marked with the right context so they match the SELinux policy for what the
given daemon is allowed to see.

So I think what one really wants is just a better level of admin/packaging
coordination.  That is, you would really like to write in one place both
the SELinux policy and the port numbers (i.e. iptables matching rules) you
want to associate with contexts.  Then you want that to generate iptables
rules that both allow packets and mark them, and you want those sets of
rules to come along the daemon's installation or something like that such
that it is easy to say "enable this daemon" and get correct iptables rules
configured on your system.

All that said, I probably still missed some major point about how SECMARK
actually works.  I have no idea.


Thanks,
Roland

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

Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)

2009-07-24 Thread Simo Sorce

On Fri, 2009-07-24 at 17:44 -0400, Simo Sorce wrote:
> On Fri, 2009-07-24 at 16:21 -0500, Bruno Wolff III wrote:
> > I thought the idea was to label packets based on source and
> > destination
> > (including ports) not application. Applications would get access to
> > the
> > packets based on their context and the context (labels) of the
> > packets.
> > I may have misunderstood though.
> 
> What's the value of labeling packets based on source/destination ports ?
> Doesn't seem to add any new information.
> 
> If I get a packet for port 8080 it's always going to whatever
> application is listen on port 8080, unless you label the packet with an
> application context SElinux does not have any more information.
> 
> now if you allow to apply application labels to packets then you could
> say that packets directed to 8080 are labeled squid_t and not apache_t
> and that would make quite a difference.
> 
> It would prevent a rogue apache that gets to listen to 8080 to get any
> packet as they would be labeled squid_t which is not apache_t.

Sorry Bruno,
after re-readying what you said I think we meant basically the same
thing.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

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

Re: RFE: FireKit

2009-07-24 Thread Jesse Keating

On Fri, 2009-07-24 at 14:24 -0500, Matthew Woehlke wrote:
> > Ugh. I think C will do just fine. Its perfectly adequate without growing 
> > any tumorous appendages.
> 
> C is just fine for device drivers, just don't make me write a GUI using 
> only C ;-). ("Tumorous appendage"? I object to that...)

Get off my lawn!!

Er, I mean, please take the language war somewhere else, before this
thread grows tumorous appendages.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


signature.asc
Description: This is a digitally signed message part
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)

2009-07-24 Thread Gregory Maxwell

On Fri, Jul 24, 2009 at 5:49 PM, Roland McGrath wrote:
> So I think most of us in this discussion probably don't actually understand
> SECMARK.  I sure didn't.  I think I might now, sort of.  The SELinux policy
> just says contexts, and it doesn't say anything about the port numbers.
> The point of SECMARK is that you write port-matching rules that are what
> sets the context on those packets.  You have to write those rules by hand
> (or somehow) or else there just aren't ever any packets anywhere that are
> marked with the right context so they match the SELinux policy for what the
> given daemon is allowed to see.
>
> So I think what one really wants is just a better level of admin/packaging
> coordination.  That is, you would really like to write in one place both
> the SELinux policy and the port numbers (i.e. iptables matching rules) you
[snip]

Not just port numbers.

For example.  I might want to confine CUPS to only speak to localhost
and 192.168.1.1/32; 192.168.10.1/32; 192.168.15.3/32, so that if
something running as cups_t is compromised it can only talk to my
print servers and not phone home or get messages from an external
botnet controller.

I think SECMARK can do this, but I think that it would require me to
change the SE linux policy to only allow cups_t to touch cups marked
packets.   I think this would be much easier to administer as pure
firewall rules, i.e.

-S 192.168.1.1/32 --dctx cups_t -j ACCEPT
...
--dctx cups_t -j REJECT

--sctx cups_t -D 192.168.1.1/32 -j ACCEPT
--sctx cups_t -j REJECT

As far as I can tell the only way to get the same general behavior
from SECMARK is it to make the SELINUX policy require the marking then
have a bunch of marking rules.  Then your apps break if the firewall
is not activated. I consider this a bootstrapping problem.

I'm also not sure how you could achieve multiple contexts being
permitted to access a particular set of traffic using secmark  nor can
I figure out how you could accomplish the output side.

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

Re: RFE: FireKit

Matthew Woehlke wrote:
> Björn Persson wrote:
> > That's obscurity, not security.
>
> Why is it people seem to have a problem with obscurity *on top of*
> security? What's wrong with making it as hard as possible for the "bad
> guys"?

It could be because you're not actually making it any harder for the bad guys, 
only for yourself and for me.

> > If there's a hole in Sendmail for example,
> > then attackers trying to exploit that hole won't start by probing port
> > 26384 and then connect to port 25 only if they get an RST packet from
> > port 26384.
>
> ...and if I happen to not be running sendmail at the time, my machine
> will appear to not exist, rather than going on the 'try other exploits'
> list. (Especially if I happen to be not running /any/ services at the
> time and am therefore truly stealthy.)

Your address will go on the "try other exploits" list anyway, because the bad 
guys know that many people think they're more secure if they're "stealthy". 
They won't conclude that your machine doesn't exist. They'll only conclude 
(correctly) that there's no public SMTP service at that address.

> > You're not truly "stealth" unless you drop *all* packets, at which
> > point you can just as well unplug the network cable (or turn WiFi off
> > with the kill switch).
>
> Not all packets, just incoming ones that don't belong to established
> connections. (I'll assume we're not talking about a black hat to whose
> server you have explicitly connected.)

You're also assuming that the attacker doesn't already own any of the other 
machines in the local network, or café, or airport, or wherever you are at the 
moment. If he does, he'll be able to eavesdrop your established connections, 
and probably hijack them too. Even if those connections are encrypted and 
authenticated he'll still discover that your machine exists, despite all your 
stealthiness.

> Besides, you didn't address the original question: if DROP is as
> non-useful as you claim, why does it exist?

I did address that question. DROP exists so I can DROP disallowed broadcast 
and multicast packets and REJECT only unicast packets. If I'd REJECT broadcast 
packets I'd violate some RFCs and become a traffic multiplier for DDOS attacks.

Björn Persson

signature.asc
Description: This is a digitally signed message part.
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: RFE: FireKit