Re: Security issue? Daemon users has to much rights...
Greetings,
Am Freitag, 22. Oktober 2004 14:02 schrieb Daniel Pittman:
> 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.
sure.
> 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.
Of course.
> 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.
That's true as well. But the binaries are just an example for unnecessary
rights.
> Even preventing them from having access to libc doesn't really help
> much. :)
Of course not. But on the other hand, there are parts of the system, a deamon
user should not be able to stick his nose in. Imho a more restrictive way is
necessary.
For instance access to the mount command is not that critical, but hijacked
daemons (take a hijacked cups for instance) allow to use local root exploits,
a remote attacker would never have been able to. Forgotten suid-binaries are
a great risk.
> > 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.
Ok, but why should lp (as user) be able to access mount (suid)? I see no
reason to allow them to do so, but I see many reasons for not allowing them
to do so.
> 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.
NSA is evil by default ;-)
Of course, providing security on that level is not the best way to ensure the
system's integrity and safety.
But why do you think, that security on filesystem level is doomed to failure
if it's part of a security concept?
The introduction of shadow passwords use the concept of file system level
security.
Imho allowing $daemon to access $some-unnecessary-suid-binary is doomed to
failure.
> > 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.
Well, yes. Sid might be a target as well.
Keep smiling
yanosz
Reply to: