On Tue, 2005-04-26 at 20:39 -0400, Eric Paris wrote:
> Some ntp clocks like the the wwvb1 which are configured with a line like
>
> server 127.127.4.1 minpoll 3 maxpoll 4
>
> in ntp.conf will need to talk to a "clock device" at /dev/wwvb1. In
> reality the clock is connected to something like /dev/ttyS0 where ntpd
> would normally have permissions. But for these types of clocks we have
> to create a sym link ln -s /dev/ttyS0 /dev/wwvb1 because ntp recognizes
> the clock as being at /dev/wwvb1.
>
> We get denials like
>
> audit(1114388976.276:0): avc: denied { read } for pid=23691
> exe=/usr/sbin/ntpd name=wwvb1 dev=tmpfs ino=148116
> scontext=root:system_r:ntpd_t tcontext=root:object_r:device_t
> tclass=lnk_file
>
> which can be fixed with
>
> allow ntpd_t device_t:lnk_file read;
>
> It might also want write permission, I'm not sure right now. I'm
> looking for comments on the right way to fix this. Is adding this or
> maybe rw_file_perms the way we really should go about this?
Write permission wouldn't make sense for a symlink. It might need
create permission if it is responsible for creating the symlink, but
hopefully not, as that would also require write and add_name permission
to the /dev directory. Hence, I'd go with the allow rule you listed
above.
BTW, if we ever want to introduce a distinction between following
symlinks during pathname lookup vs. just reading their content via
readlink(2), then we need to start introducing macros to distinguish
those uses and using those macros pervasively rather than directly
writing allow rules on lnk_file. I posted a trivial patch to the
SELinux module a while back that used a separate permission for
following symlinks in response to discussion by Russell Coker (so that
you can prevent an admin from following an untrustworthy and potentially
malicious symlink while still allowing him to see what it references via
ls -l), but incorporating that change would require a thorough audit of
policy to update all existing lnk_file references, and no one has
undertaken that work to date.
--
Stephen Smalley <sds@xxxxxxxxxxxxx>
National Security Agency
|
