Hello, in net-misc/dhcp-3.1.1 /etc/dhcp is installed with 0755 mode. This is unsecure, because ordinary users may access private data such as MAC-addresses of registered clients. The same applies for chrooted variant of dhcp. Solution: change group of /etc/dhcp to "dhcp" (ownership root:dhcp), and use mode 0750.
base-system: Please advise.
mmm, MAC addresses do not qualify as "secret" data. what other "private" data is in there that you want to keep hidden ?
(In reply to comment #2) > mmm, MAC addresses do not qualify as "secret" data. what other "private" data > is in there that you want to keep hidden ? It is still arguable what whether these qualify as "secret" or "private". Your opinion is only one of many. The question is rather whether Gentoo should protect this information from other users of the system. If /etc/dhcp/dhcpcd.conf is meant, then it is as readable as is /etc/passwd (registered users of the local system) and the like. However, if /etc/dhcp/lib -> /var/lib/dhcp/ is readable, this reveals dhcpd.leases* containing timestamped login information, alike /var/log/(lastlog|wtmp). It is a valid point that in some configurations it is crucial to keep the dhcp information private. Does anybody have a good argument why those files should stay world-readable? If it doesn't break anything, then I suggest changing the default permissions.
so the answer is "no, there isnt anything in there"
(In reply to comment #4) > so the answer is "no, there isnt anything in there" The answer is "you should restrict all permissions to the most strict level on which your system still can operate flawlessly". And yes, I'm considering MAC-addresses as a private information. In some environments they may be spoofed of course, but is some you can't do that. Also MAC-based network security is often used as a first layer of the whole security model. Aside from that, other protected may occur in the file: for some registered clients special routes and services may be given via dhcp, which should not be accessible by others. Of course, in my case those routes and services are protected via iptables and SSL authentication for some of them, but nevertheless I do not even want to let third-party know that they exist. And do not forget, that using MAC you may identify hardware being used by the client and, sometimes, country where it was shipped and customer who bought it. This is private data.
(In reply to comment #4) > so the answer is "no, there isnt anything in there" No, my answer was that parts of the Linux security model are somewhat broken by design (/etc/passwd etc which might leak certain sensitive info to non-root users). Even if /etc/passwd etc files are part of the security models bad design, doesn't mean we shouldn't try to keep DHCP and other stuff secure. And IT IS more secure to have "chmod o-rwx" for DHCP files.
if you were truly concerned, you wouldnt be let random users access the dhcp server in the first place. MAC addresses are not "secret" or "private" or anything else. that's crap. anyone on that box or even same network segment can figure those out. unless you guys have actual data that needs to be kept private, i'm not inclined to change the current behavior.
(In reply to comment #7) > if you were truly concerned, you wouldnt be let random users access the dhcp > server in the first place. This is not the matter here. An offender may obtain local user shell using bugs in another software; and in some cases dhcp server provides dozen of other services as well: users may have ssh shell absolutely legally. If you are relying on physical isolation of the machine per task, this is silly. If you want to deliberately lower security layer just because it will be at this moment overlapped by another one — this is even more silly, this is barely professional. I may remind you how you insisted on critical glibc bug 341755 that the second patch should not be applied prior to fix security issue, just because you were sure that FEATURES="sfperms" is sufficient to do that, but it occurs later that it doesn't. The same is here, you are insisting on reducing system security just because you are sure that another arrangements will be sufficient. > MAC addresses are not "secret" or "private" or anything else. that's crap. > anyone on that box or even same network segment can figure those out. Not always, on my LAN ebtables are engaged and offender will not be able to spoof MAC from another segment of the network. > unless you guys have actual data that needs to be kept private, i'm not > inclined to change the current behavior. If you read my previous post more carefully, you will find examples of such data: routes and services announced only for selected clients.
(In reply to comment #7) > MAC addresses are not "secret" or "private" or anything else. that's crap. > anyone on that box or even same network segment can figure those out. Not necessarily. That's crap. > unless you guys have actual data that needs to be kept private, i'm not > inclined to change the current behavior. Then please give us at least one good reason (besides being lazy) why these configuration files should be world-readable? Would it break something if they were not world-readable? Would it be a risk of some kind? What reason? Currently I don't see any reason for these files to be world-readable, and the safest solution appears to be to change the permissions accordingly. Is this really so hard to do for just to be sure? Better safe than sorry.
if your network security is based on people not knowing information that is easily detected or can be guessed to bypassed, it is crap. since no one has yet to post examples of information that needs to be kept secret, i'm not inclined to change anything in the ebuild. you'll need to convince someone else with your security hand waving.
I, as a part of the security team and a admin think that this is not an issue. Thus closing WONTFIX. You are free to change the rights by yourself if you really think this is a issue.
(In reply to comment #11) > I, as a part of the security team and a admin think that this is not an issue. > Thus closing WONTFIX. You are free to change the rights by yourself if you > really think this is a issue. Please at least add an ewarn message to the ebuild: ewarn "By default, client registration data in /etc/dhcp/ and client session data in" ewarn "/var/lib/dhcp/ are world-readable, which might be an undesireable information" ewarn "leak for some configurations. If this is the case for your system, please " ewarn "change the filesystem permissions manually."
