Re: Security issue? Daemon users has to much rights...
On 22 Oct 2004, Jan Lühr wrote:
> because of the recent xpdf issues I tested the access restrictions of some
> users like lp, mail, etc. with default settings in sarge. I noticed that, by
> default, no acl were used to prevent access to vital system commands, the
> user shouldn't have. For instance: lp could mount a vfat partion marked as
> user mountable in fstab, execute df or mount to gain information about the
> systems topology.
I don't think that you understand what an "ACL", or Access Control List,
is -- or, possibly, you have learned an uncommon use of that terminology
elsewhere.
Access Control Lists are almost always used in the context of extended
filesystem permissions, as a way of granting or revoking more than the
simple user/group/other spilt traditional to Unix.
They are not the usual technology used to provide access partitioning to
the system in the style you suggest above, although they can in some
cases make it easier to implement that sort of security policy.
This is, in large part, because preventing access to the binaries
commands on disk does little or nothing to prevent a determined attacker
from gaining the equivalent functionality through directly calling the
kernel.
Even preventing them from having access to libc doesn't really help
much. :)
> By introducing acl's in late 2.4 and 2.6 (both are the main kernel branches
> for sarge and are used during the installaion), it might be worth the effort
> to introduce default ACLs during the installation process (optional of
> course) in order to protect systems not managed by skilled admins. (rentable
> server, etc.)
> What do you think?
I think that trying to enforce this sort of security at the filesystem
level is doomed to failure, as it is the wrong level to work at.
If you want to achieve this sort of high level security by default,
consider finding and working with the people who are trying to provide
the tools and environment required to run SELinux, or some other MAC
implementation, in Debian.
> Who's in charge with this decision?
I don't think you could succeed in having this imposed by fiat on the
Debian project, especially at this late stage, since it would be a huge
level of work.
Regards,
Daniel
--
We live in a moment of history where change is so speeded up that we
begin to see the present only when it is already disappearing.
-- R.D. Laing
Reply to: