Bug#25847: general: Several security questions
On Mon, 17 Aug 1998 at 19:48:10 +0200, Patrik Rak wrote:
[OK, let's see how many of these are done, nearly three years later ...]
> The log file /var/log/dpkg-mountable is world readable. It might be risky if
> some of the configurations scripts asks for some password or like...
dpkg-mountable has been removed in woody.
> Is it ok that smail logs containg information about mail delivery are world
> readable?
In 1999, rcw suggested this was no longer valid; I don't know enough
about smail to check.
> The mountpoints /cdrom and /floppy are set to g+wxs. However, I think that
> the g+w flag is of no use here, as when a fstab entry with 'user' option
> enabled is mounted, the access flags are changed and the mount point is
> owned by respective user since then anyway. So the g+w just allows users in
> the cdrom and floppy groups to store files on your root partition (when
> /cdrom resp. /floppy is not mounted), which I don't consider useful.
>
> I doubt that the g+s is of any use as well, and so is the setting of the
> gids of these mountpoints to group cdrom resp. floppy.
Fixed, according to the base-files maintainer.
> Is it ok that anybody can use logger (resp. /dev/log) to fill all space in
> /var/log?
There is a section in the syslogd(8) man page describing ways to prevent
this:
SECURITY THREATS
There is the potential for the syslogd daemon to be used
as a conduit for a denial of service attack. Thanks go to
John Morrison (jmorriso@rflab.ee.ubc.ca) for alerting me
to this potential. A rogue program(mer) could very easily
flood the syslogd daemon with syslog messages resulting in
the log files consuming all the remaining space on the
filesystem. Activating logging over the inet domain sock
ets will of course expose a system to risks outside of
programs or individuals on the local machine.
There are a number of methods of protecting a machine:
1. Implement kernel firewalling to limit which hosts
or networks have access to the 514/UDP socket.
2. Logging can be directed to an isolated or non-root
filesystem which, if filled, will not impair the
machine.
3. The ext2 filesystem can be used which can be con
figured to limit a certain percentage of a filesys
tem to usage by root only. NOTE that this will
require syslogd to be run as a non-root process.
ALSO NOTE that this will prevent usage of remote
logging since syslogd will be unable to bind to the
514/UDP socket.
4. Disabling inet domain sockets will limit risk to
the local machine.
5. Use step 4 and if the problem persists and is not
secondary to a rogue program/daemon get a 3.5 ft
(approx. 1 meter) length of sucker rod* and have a
chat with the user in question.
Sucker rod def. -- 3/4, 7/8 or 1in. hardened steel
rod, male threaded on each end. Primary use in the
oil industry in Western North Dakota and other
locations to pump 'suck' oil from oil wells. Sec
ondary uses are for the construction of cattle feed
lots and for dealing with the occasional recalci
trant or belligerent individual.
> Is it ok that anybody can write to /dev/console (resp. /dev/tty0)?
> If not, makedev's devinfo is not ok.
/dev/console is now created with mode 0600.
> Is it ok that currently unused (i.e., no one logged on at the moment, and
> getty is waiting there) /dev/tty1-6 are chgrp dialout and chmod 0660? I
> thought that dialout is for accessing the modem lines, i.e.,
> /dev/ttyS0-4, and I would expect chgrp tty on tty1-6.
They're root:root mode 0600 on my system, but I'm running mingettys.
Anybody?
> Is it ok that anybody can write anything to any
> other tty (/dev/tty7-63) (fake log messages on /dev/tty8 come in mind) ?
If you use a tty for logging, you should probably restrict its
permissions ... your changes should be preserved.
> Is there some deep purpose for vcs0-6 and vcsa0-6 (i.e., the used ones)
> being chgrp sys while others vcs's and vcsa's are chgrp root?
MAKEDEV creates them all root:root mode 0600 now (at least looking at my
recently installed laptop).
If #2 is really done, and if #6 is the same for gettys as for mingettys,
then all of the other concerns seem to have been addressed by now. Can
we close this bug? Otherwise we should reassign it to whichever
package(s) still have problems.
Cheers,
--
Colin Watson [cjwatson@flatline.org.uk]
Reply to: