Re: Security issue? Daemon users has to much rights...
On 23 Oct 2004, Jan Lühr wrote:
> 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.
[...]
>> 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.
Yes, and that is one of the core points in my suggestion that you look
at SELinux or a similar mandatory access control based security module.
[...]
> 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.
MAC allows you to actually enforce these rules, rather than simply
making it a bit harder or the mechanism a bit more obscure.
As people have been saying for years, security through obscurity is no
real security at all -- and preventing access to on-disk binary code
does not prevent access to the risky areas.
[...]
>> 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.
They shouldn't be able to access mount, or related functionality.
Trying to enforce that through filesystem permissions is a task that has
a large number of failure points, especially in the face of multiple
vulnerabilities.
One of the most common failures for this sort of security is a copy of
the binary accessed through another path name, etc, that allows the
undesired code to be executed despite protection in of the main copy.
Also, trying to define the security rules at the filesystem level
provides no real protection against many locally exploitable holes.
Many of these can be accessed by talking over network sockets or other
channels than the filesystem.
>> 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 ;-)
The code is all out there; feel free to audit it. ;)
Alternatively, trust some other group who write LSM code to implement a
MAC system, or even one of the alternative security models, and work on
getting that into Debian as an option or, eventually, by default.
I named SELinux because I know there to be a real effort to get this
working out of the box, not because I have any special love for it.
> 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.
You may note that the shadow password system has also moved on, to
include other methods for encrypting the password since, at the end of
the day, these filesystem permissions can be bypassed. :)
You are right when you say that using filesystem permissions can provide
some measure of additional security, and when you say that the
introduction of an ACL capability into many common filesystems in Linux
opens the door to enabling this.
Between the complexity of the ACL system, the difficulty in defining
security rules for a full blown Unix, I don't believe that this can
work.
Also, I believe that there is a good deal more work in making this
security system accessible out of the box than you suggest.
However, this is a volunteer project - if you think it is helpful, go
ahead and lead the effort. I will happily be proved wrong when your ACL
security project shows up real world benefits.
>>> 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.
Practically, what you probably want to do is work on getting ACL-enabled
tools into base, and then start working through and getting individual
packages enhanced to use them.
I wouldn't expect to see significant gains within six months to a year
of concentrated effort from a number of people when dealing with a
project of this scope.
Regards, and good luck,
Daniel
--
Onanism produces seminal weaknesses, impotence, dysury, tabes dorsalis,
pulmomary consumption, dyspepsia, dimness of sight, vertigo, epilepsy,
hypochondriasis, loss of memory, manalgia, fatuity, and death.
-- Dr. Benjamin Rush, _Medical Inquiries_, 1812
Reply to: