| Michael Paoli 2006-03-15, 2:46 am |
| john wrote:
> The default DIR_MODE in debian's adduser.conf is 755 and the default file
> umask is 022, so it looks like home directories are world readable in
> Debian. Does login.defs have any impact at all on Debian, given that Pam
> is in use? Isn't the default umask set in /etc/profile anyway? If I can
> set my own should it be in ~/.bashprofile or ~/.bashrc?
DIR_MODE in Debian's adduser.conf only impacts the mode of the home
directory when it's first created via adduser. UMASK in Debian's
login.defs can be used to set a umask value for login sessions. PAM
and other files can be used to set umask values. Depending on various
factors, potentially also including one's login shell, they will
generally apply in a hierarchial order. The higher up the setting is
made, the more "global" or "universal" it acts - at least as a
default. Typically users can tweak these to their liking, or insure
they get what they want, even if the system default is not to their
liking or preference, by suitably adjusting their startup file(s),
e.g. ~/.profile Where, and/or if one should set those in specific
file(s) depends upon when and how one wants them to take effect.
> I think there should be conservative, private settings "out of the box",
> but that's just me.
Reasonable opinions will differ. I tend to lean that direction, but
many environments favor a more "open" environment - e.g. sharing read
access to most or much stuff, unless otherwise explicitly denied. This
can also be easier (but less secure) for users not so familiar with
the permissions mechanisms of LINUX/UNIX/etc.
> I think the permissions system is a good tool, and not setting them
> properly because "it probably won't help anyway" seems kind of flaky. The
> rogue user who tries to install and run a rogue program should be defeated
> by a well designed file permission system. That's the whole problem with
> Windows is that permissions are too slack. Shouldn't linux try to build
> on its strenths in this area?
Well, "properly" may be a subject of debate - as to its definition,
for starters. Making something readable and/or executable
(particularly also if it lacks SUID/SGID), particularly if it's quite
commonly available elsewhere anyway, and nothing would prevent the
user from writing out a similar binary (and owning it and setting the
permissions to their liking), then denying read/execute on it isn't
all that useful in general. E.g. I can think of a particular
commercial UNIX where the vendor has ntpdate readable, but not
executable, for ordinary users. I find this a futile waste, as I
occasionally want to run ntpdate (with the -u and -q options) as a
mere mortal user on said UNIX - so what do I end up doing? I copy the
binary, set the execute permission on the copy, and run that. It's
rather wasteful, but it's more secure than my becoming superuser just
to run the binary in the same manner. Likewise for fuser on some
commercial UNIX flavor(s). Denying users access to this kind of stuff
often ends up with lots more copies of such running around the system
anyway.
> I think Linux needs to improve by cleaning up the user interface. There
> are too many ways to do things, config files that have to relevance
> because another package is overriding it. eg login.defs overridden wholly
> or partly by the existence of Pam. Debian installs both /etc/pam.d *and*
> pam.conf - why the hell is that? Somewhere in the bowels of Pam is a
> provision that says if both exist, then /etc/pam.d will determine the
> configuration. Sheesh.
> There should be *one way* to set something, and it should be effective and
> well explained.
In UNIX and LINUX, there are often many ways to do things. This is
generally a good thing. One can pick the most efficient, or the one
one is most familiar with. I think many folks prefer not being told
that there's only one way to do something and if you want to do it you
must do it only that way, and no other way. By the time you get down
to the system call level, there often may only be one way to do
something, but at higher levels of abstraction and commands, there are
often multiple ways to accomplish the same tasks or effects.
> I was reading in Aileen Frisch's Essential System Administration book
> about her recommendations for making system changes - one of them is "test
> test test" before "releasing it on the world". If someone with her
> experience and knowledge isn't sure what the effects of her system changes
> will be, what chance does the average joe have to run a linux system
> reliably and securely?
Yes, good book, good advice. There's lots of great documentation out
there, but sometimes the documentation isn't fully clear, complete,
and correct. Testing is generally a good thing. Also, with, e.g.
Debian, if/when one finds the documentation in error or missing
crucial information, one has better opportunities to submit that
information, and it's more likely to actually get included in future
releases.
> Debian should ship with *no servers* installed or running - by default.
> And nice private settings for home directories - by default. People who
> want to run servers will no doubt be able to figure out how to run them.
> People who don't know that they shouldn't be running them will not be able
> to stop them or even have much chance of realizing that they shouldn't be
> running them.
If one merely does the "base" install on Debian, I think one does get
that situation - no "servers" running - at least not any network
services, ... or at least exceedingly close to it. There's a
trade-off here between ease-of-use and security. Some systems (e.g.
OpenBSD) lean more towards security - no running network servers by
default, when the programs are added, by default they don't start,
etc. This can be rather painful, however, for those less familiar
with UNIX/LINUX/BSD - often they want and expect, that when they
install some network service package (e.g. Apache), that they ought to
get a good working default configuration to start off with, and that
it should be reasonably secure by default, but it should be
functioning and operational. Many vendors/distributions play this
balance between security and ease-of-use, landing various places along
that spectrum.
Personally, what I'd like to see and advocate, is a relatively
high-level configuration file, that one could set and specify how one
wants
these things to behave by default, e.g. something roughly like:
#NEWLY_INSTALLED_SERVER_STARTS_BY_DEFAUL
T=YES
NEWLY_INSTALLED_SERVER_STARTS_BY_DEFAULT
=NO
#NEWLY_UPGRADED_SERVER_STARTS_OR_RESTART
S_BY_DEFAULT=YES
#NEWLY_UPGRADED_SERVER_STARTS_OR_RESTART
S_BY_DEFAULT=IF_ENABLED_IN_CONFIG
#IF_ENABLED_IN_CONFIG would suitably consult [x]inetd.conf, rc files
#and run state, and configuration for that server service
#would restart it if the upgrade first stopped running server
#NEWLY_UPGRADED_SERVER_STARTS_OR_RESTART
S_BY_DEFAULT=IF_WAS_RUNNING
NEWLY_UPGRADED_SERVER_STARTS_OR_RESTARTS
_BY_DEFAULT=NO
> I'm not trying to start any arguments either, just offering my opinions on
> these issues, for what they are worth. Linux could be *so much better*
> than windows, but changes need to be made to realize that potential.
LINUX (and Debian) *is* *so much better*! ... but that's for
comp.os.linux.advocacy
john wrote:
> I forgot to add that I think Debian should be leading the way, too.
To a large extent, Debian is leading the way. If you look at usage of
major LINUX distributions, and how many of them are based upon or use
much from Debian, and also Debian's influence on LSB, DCC, UNIX and
BSD and other standards, Debian is a major player, and in many areas
leading the way (if not directly, at least by influence and
contributions).
|