[linux-elitists] Integrating the firewall and the package manager?
Karsten M. Self
Sun May 1 15:55:03 PDT 2005
on Sun, May 01, 2005 at 11:11:16PM +1000, Mike MacCana (email@example.com) wrote:
> Karsten M. Self wrote:
> >on Sun, May 01, 2005 at 04:22:58AM +1000, Mike MacCana
> >(firstname.lastname@example.org) wrote:
> >>But the user's already selected what rules they want by specifically
> >>electing the service starts by default in that runlevel.
> >Presumes the service is intentionally started by the user.
> Presumes the app is packages correctly, yes.
> >Too: I've heard that GNU/Linux can be run as a multiuser system, though
> >for the life of me, I can't think of why anyone would want to to that,
> >or anyone who does.
> You mean the average desktop user doesn't find Ctrl Alt F1, username,
> passwd, 'startx -- :1' intuitive?!?!
> Gnome/GDM seem to have sorted that out recently tho.
Indeed. A shell wrapper to hunt for a fresh X slot is another (I just
wrote one). XDMCP, LTSP, and VNC-via-[x]inetd are other commonly
deployed options. And there's a hell of a lot more shell sessions
flying around than the MSM wants to fess up to.
I know you don't speak for RH, but I find the local-single-user-desktop-
centrism implicit in a lot of stuff I see from distros and several major
projects to be annoying. We've got an inherently multi-user,
network-accessible base. Let's keep that in mind. Even MSFT have made
big strides in this direction (various remote desktop and terminal
server options) with more on the way. Even if it's not your _primary_
access method, it's a hellatiously convenient anciallary one. GNOME
seem to be exhibiting some minor clue in this regard lately.
> >>If packages are starting network services (that listen on more than
> >>localhost) by default, that's a bug in that package and should be
> >>fixed in the package.
> >Good policy, bad assumption.
> Common practice from what I've seen YMOV (the O standing for
> obviously). Again, I think having the user specifically elect to do
> things twice is a Bad Thing, and keeping it outside the service file
> due to policy problem is a technical solution to a policy issue, and
> hence won't work.
My point is that once you've got n users on a system, for values of n >
0, mentally tracking what should or shouldn't have connections open,
and/or presuming all apps / processes are installed / configured through
the PMS typically runs into a theory :: reality impedence mismatch.
In particular for high-numbered ports, pretty much _any_ process can
establish a connection, viz: telnet or netcat.
Don's original suggestion:
- Greatly simplifies firewall maintenance for the nontechnical, or
- Provides a belt'n'suspenders level of assurance if you really do
want to block arbitrary high-numbered ports. If it's not an
officially registered service, managed via PMS, it's not going to
get out. Your users can't shoot you in your feet. Yes, this also
means you need an exceptions management capability for the firewall.
- As an additional level of managing who can do what, I'm strongly
attracted to Don's proposal.
Yet another thought that's occured to me: is there any reason why
permissions to specified ports couldn't be handled a'la file
permissions? On a user/group r/w level?
The low-numbered ports system was proposed when root was implicitly
trusted, and the risks of exposing root to arbitrary data weren't fully
considered. In this day and age, I'd be a lot happier if I could assign
read access to :80 strictly to www-daemon, say (not www-user, who owns
the webfiles). Or :22 ssh-daemon, or :53 bind, etc. Similarly, users
could be granted or denied access to specified ports as well.
I'm certain I'm not the first person to suggest something like this,
what are the implementation problems and/or limitations on actual
1. Package management system.
Karsten M. Self <email@example.com> http://kmself.home.netcom.com/
What Part of "Gestalt" don't you understand?
The truth behind the H-1B IT indentured servant scam:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : http://allium.zgp.org/pipermail/linux-elitists/attachments/20050501/ebe8a863/attachment.pgp
More information about the linux-elitists