sudo without password

[ubuntu at rio.vg]

Alan McKinnon wrote:
> 
>> It's the human component, as you say.  If your security model is
>> too much of a pain in the rear to set up and maintain, it will fall
>> apart. Quite often, the simpler the solution, the more secure it
>> will be in the long run.
> 
> This probably explains why SELinux is less prevalent than it should 
> be, given it's capabilities
> 

Or perhaps why it *shouldn't* be prevalent.  SELinux, of course, is good
 for some systems, but it is mostly too much of a pain in the rear, so
it is more likely to be set up poorly, which might even be worse than
not having it at all.

>> I just first tried Ubuntu for the first time with the release of
>> Dapper, and I was rather surprised it did not install a
>> host-firewall by default.  I understand Ubuntu's take of "we don't
>> install anything that listens", but that quickly falls apart when
>> the user starts installing things like NFS that require portmap,
>> for instance.
> 
> Now that's a good way to start a "vigorous discussion" (like the 
> compiler one that's going on elsewhere). A port-based and a 
> host-based firewall on a workstation seems like a good idea to us 
> old-timers, but the problem with these is that they require an 
> enormous amount of knowledge from the user. *I* can't remember which 
> port imap runs on (that's why I have /etc/services), so I wouldn't 
> expect the average user to know. Thanks to dhcp and dynamic ips, the 
> average user can't be expected to filter hosts more fine than local 
> network/not local network. I'm not saying that these problems can't 
> be solved, it's just that I haven't seen a solution for them yet that 
> is suitable for mass deployment.

I don't mean it to spark a flame war, certainly.  I just see it as an
area in which Ubuntu could improve.  I think it's something worth
discussing.

That said, from using other distros, other set it up for filtering
incoming only.  Thus, you don't need to know what ports things use,
unless you're setting up server process.  Moreover, there are plenty of
GUI-based systems for managing iptables where you don't need to know the
port numbers.  If you're setting up an IMAP server, you'd just check off
or type in "IMAP".  For most users, the firewall would be completely
invisible, since they generally don't need to have anything listening to
the network.

One thing I haven't seen for Linux is something like ZoneAlarm, that
would bring up a dialog when something tries to make outgoing
connections for filtering aswell.  At this point, it isn't nearly as big
of an issue, since Linux has far fewer malware issues as Windows.

Obviously, that wouldn't work for a server, but as Linux desktops become
more common, malware designed to attack Linux will start to spread.
This is what I really worry about with the old-style Debian approach.
It assumes that malware won't get onto the machine.  As we look to the
future, I think this is going to be a problem at some point.

>> As an aside, another interesting notion, I think, was released with
>> SuSE 10.1: AppArmor.  The idea is to restrict programs, rather than
>> users. Effectively, you create access lists of what a particular
>> program is allowed to access.  Much the same deal as chroot, but
>> with far less hassle.  (Since you don't actually have to copy it
>> all into a single path)
> 
> I keep intending to investigate this product and never get round to 
> it. Is it so that the user can for example block everything except 
> connections initiated by Firefox and Thunderbird, and allow incoming 
> port 80? If so, that strikes me as a better approach than tcpd & 
> iptables.

AppArmor isn't really related to network activity or firewalling.  It's
more of an alternative to chroot, as I understand it.  I've been reading
a bit about it, but I haven't had a chance to design my own configs for
it.

While chroot is very powerful, it has some major disadvantages.
Everything the program can see needs to be copied into it's own area.
It's awfully limiting.  AppArmor is like an access list for a program.
Not who can access the program, but a list of what the program is
allowed to access.  This way, apache can't write to /tmp, for instance.
 By limiting what a program can do, you limit the damage any exploit of
that program can do.  Most buffer overflows in web apps will try and
stick their rootkit in /tmp, this cuts it off.

The standard server apps come with their own apparmor profiles, so
individual users won't have to create their own.  If they have something
odd, the configs are pretty straightforward.  For instance, here's the
IMAP one:

/usr/sbin/imapd {
  #include <abstractions/base>
  #include <abstractions/nameservice>
  #include <abstractions/authentication>
  #include <abstractions/user-mail>

  /dev/urandom                              r,
  /tmp/*                                    rwl,
  /usr/sbin/imapd                           r,
  /usr/share/ssl/certs/imapd.pem            r,
  /usr/share/ssl/openssl.cnf                r,
}

It's not something for the average user, but fairly straightforward for
administrators, should they need to edit it.