tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: -current's /etc/security wrongly detects "." in root's path



Alan Barrett <apb%cequrux.com@localhost> schrieb:
> Does the appended patch work?  The idea is to make $TMP1 an empty file
> if $PATH is empty.

It cures the symptoms I was seeing, but, as you say:

> However, it might be better to set PATH to some default value before
> sourcing the file.  This will allow it to report things like "Root path
> directory /bin is group writable" even if /etc/profile or ~root/.profile
> do not explicitly set PATH.  But what default would we use?  login(8)
> uses setusercontext(3) but I don't know of a command-line interface to
> that.  It would be easy enough to use a hardcoded default, or sysctl
> user.cs_path, but neither of those is exactly right.

The way the security script obtains root's PATH is pretty flawed,
because it does not honour, and cannot easily so, the default path
for root's login class set in login.conf. It does not seem difficult
to construct pathological cases where it would still produce false
positives even with your patch applied, not to speak of false
negatives. Unfortunately, I don't see a way to fix this satisfactorily,
because, as you say, there does not seem to be a command-line
interface to the login.conf mechanism.

I tend to think that this part of /etc/security should be removed,
even though it would be quite nice to have...

--
Dennis den Brok



Home | Main Index | Thread Index | Old Index