Re: security - preferred way to make check_access_file happy?

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: security - preferred way to make check_access_file happy?

Adam Thompson
Whoops... I'm getting the messages from 3 systems, all running
6.4-STABLE, with no local modifications, under both VMware and
Openstack, using openup to keep systems updated.  Dmesg available if
anyone thinks it's relevant.
-Adam


On 2019-02-25 08:50, Adam Thompson wrote:

> Hi,
> I'm getting daily insecurity (i.e. security(8)) nags about userids
> that are off but still have a valid shell and access files.
> (Specifically, I'm getting the nag from check_access_files() in
> /usr/libexec/security.)
>
> Since ports (at least in my experience) regularly creates userids that
> will trigger this warning, what's the "best" way to disable the
> warning?  I'm reluctant to mess with permissions on directories
> created by packages, but maybe that's the best way?
>
> Otherwise, it looks like I can disable the warning by setting a
> password on the userid in question.
>
> However, that leads to the question: what if I don't *want* a password
> on the account, because it's supposed to be a SFTP-only,
> public-key-authentication-only account, but still needs to be readable
> and needs a valid shell for various cron jobs to be happy?  If I'm
> following the logic correctly, one of the warnings I'm getting is for
> ~/.ssh being readable on a userid with no password - exactly the
> scenario I just mentioned.  But AFAIK they can't login if I take away
> S_IRUSR on ~/.ssh?
>
> The most distasteful option is to hack /usr/libexec/security to ignore
> certain userids, but ... it's there for a reason.
>
> The cleanest example I have right now from ports is _rancid, created
> by the rancid package, and triggered by the existence of ~_rancid/.ssh
> with S_IRUSR (u+r) permissions.
>
> Suggestions / advice?
>
> Thanks,
> -Adam

Reply | Threaded
Open this post in threaded view
|

Re: security - preferred way to make check_access_file happy?

Solene Rapenne
On Mon, Feb 25, 2019 at 08:50:18AM -0600, Adam Thompson wrote:

> Hi,
> I'm getting daily insecurity (i.e. security(8)) nags about
> userids that are off but still have a valid shell and access
> files.  (Specifically, I'm getting the nag from
> check_access_files() in /usr/libexec/security.)
>
> Since ports (at least in my experience) regularly creates
> userids that will trigger this warning, what's the "best" way to
> disable the warning?  I'm reluctant to mess with permissions on
> directories created by packages, but maybe that's the best way?
>
> Otherwise, it looks like I can disable the warning by setting a
> password on the userid in question.
>
> However, that leads to the question: what if I don't *want* a
> password on the account, because it's supposed to be a
> SFTP-only, public-key-authentication-only account, but still
> needs to be readable and needs a valid shell for various cron
> jobs to be happy?  If I'm following the logic correctly, one of
> the warnings I'm getting is for ~/.ssh being readable on a
> userid with no password - exactly the scenario I just mentioned.
> But AFAIK they can't login if I take away S_IRUSR on ~/.ssh?
>
> The most distasteful option is to hack /usr/libexec/security to
> ignore certain userids, but ... it's there for a reason.
>
> The cleanest example I have right now from ports is _rancid,
> created by the rancid package, and triggered by the existence of
> ~_rancid/.ssh with S_IRUSR (u+r) permissions.
>
> Suggestions / advice?
>
> Thanks,
> -Adam
>

Use vipw to put 13 * in the password field

From passwd(5)

 The password field is the encrypted form of the password.  If the
 password field is empty, no password will be required to gain access to
 the machine.  This is almost invariably a mistake.  By convention,
 accounts that are not intended to be logged in to (e.g. bin, daemon,
 sshd) only contain a single asterisk in the password field.  Note that
 there is nothing special about ‘*’, it is just one of many characters
 that cannot occur in a valid encrypted password (see crypt(3)).
 Similarly, login accounts not allowing password authentication but
 allowing other authentication methods, for example public key
 authentication, conventionally have 13 asterisks in the password field.
 Because master.passwd contains the encrypted user passwords, it should
 not be readable by anyone without appropriate privileges.

Reply | Threaded
Open this post in threaded view
|

Re: security - preferred way to make check_access_file happy?

Solene Rapenne
On Mon, Feb 25, 2019 at 09:13:33AM -0600, Adam Thompson wrote:

> > Use vipw to put 13 * in the password field
> >
> > From passwd(5)
> > [...]
> >  authentication, conventionally have 13 asterisks in the
> > password field.
>
> Thank you!  Now that I know what I'm looking for, I can see the
> relevant code in security(8), too.
>
> I wonder if there's a way for ports to do that for me while
> calling useradd?  Another rabbit hole to go down.
>
> Thanks again,
> -Adam
>

all my users installed by packages have 13 * in that
second field when I check with "doas vipw"

Reply | Threaded
Open this post in threaded view
|

Re: security - preferred way to make check_access_file happy?

Stuart Henderson
In reply to this post by Adam Thompson
On 2019/02/25 08:50, Adam Thompson wrote:

> Hi,
> I'm getting daily insecurity (i.e. security(8)) nags about userids that are
> off but still have a valid shell and access files.  (Specifically, I'm
> getting the nag from check_access_files() in /usr/libexec/security.)
>
> Since ports (at least in my experience) regularly creates userids that will
> trigger this warning, what's the "best" way to disable the warning?  I'm
> reluctant to mess with permissions on directories created by packages, but
> maybe that's the best way?
>
> Otherwise, it looks like I can disable the warning by setting a password on
> the userid in question.
>
> However, that leads to the question: what if I don't *want* a password on
> the account, because it's supposed to be a SFTP-only,
> public-key-authentication-only account, but still needs to be readable and
> needs a valid shell for various cron jobs to be happy?  If I'm following the
> logic correctly, one of the warnings I'm getting is for ~/.ssh being
> readable on a userid with no password - exactly the scenario I just
> mentioned.  But AFAIK they can't login if I take away S_IRUSR on ~/.ssh?
>
> The most distasteful option is to hack /usr/libexec/security to ignore
> certain userids, but ... it's there for a reason.
>
> The cleanest example I have right now from ports is _rancid, created by the
> rancid package, and triggered by the existence of ~_rancid/.ssh with S_IRUSR
> (u+r) permissions.
>
> Suggestions / advice?
>
> Thanks,
> -Adam
>

slightly dirty (but reliable) hack: set the password to thirteen *'s
instead of just one, so it looks like a DES crypted password instead,
like all the users present in the base OS or added by normal pkg_add.

of course this makes the /etc/security check not entirely useful,
because one could quietly create .ssh/authorized_keys for a home dir
for a "ports" uid and security won't pick it up ...

Reply | Threaded
Open this post in threaded view
|

Re: security - preferred way to make check_access_file happy?

Stuart Henderson
In reply to this post by Solene Rapenne
On 2019/02/25 09:13, Adam Thompson wrote:

> > Use vipw to put 13 * in the password field
> >
> > From passwd(5)
> > [...]
> >  authentication, conventionally have 13 asterisks in the password field.
>
> Thank you!  Now that I know what I'm looking for, I can see the relevant
> code in security(8), too.
>
> I wonder if there's a way for ports to do that for me while calling useradd?
> Another rabbit hole to go down.
>
> Thanks again,
> -Adam
>

It normally does already. Do you have an unusual "password" line in /etc/usermgmt.conf?


Reply | Threaded
Open this post in threaded view
|

Re: security - preferred way to make check_access_file happy?

Theo Buehler-3
On Mon, Feb 25, 2019 at 05:14:50PM +0000, Stuart Henderson wrote:

> On 2019/02/25 09:13, Adam Thompson wrote:
> > > Use vipw to put 13 * in the password field
> > >
> > > From passwd(5)
> > > [...]
> > >  authentication, conventionally have 13 asterisks in the password field.
> >
> > Thank you!  Now that I know what I'm looking for, I can see the relevant
> > code in security(8), too.
> >
> > I wonder if there's a way for ports to do that for me while calling useradd?
> > Another rabbit hole to go down.
> >
> > Thanks again,
> > -Adam
> >
>
> It normally does already. Do you have an unusual "password" line in /etc/usermgmt.conf?

I think the user(8) behavior changed in that regard in user.c rev 1.112
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/user/user.c.diff?r1=1.111&r2=1.112

@@ -1130,16 +1082,8 @@
  warnx("Warning: home directory `%s' doesn't exist, and -m was"
     " not specified", home);
  }
- if (up->u_password != NULL && valid_password_length(up->u_password)) {
- (void) strlcpy(password, up->u_password, sizeof(password));
- } else {
- (void) memset(password, '*', DES_Len);
- password[DES_Len] = 0;
- if (up->u_password != NULL) {
- warnx("Password `%s' is invalid: setting it to `%s'",
- up->u_password, password);
- }
- }
+ (void) strlcpy(password, up->u_password ? up->u_password : "*",
+    sizeof(password));
  cc = snprintf(buf, sizeof(buf), "%s:%s:%u:%u:%s:%lld:%lld:%s:%s:%s\n",
     login_name,
     password,

Reply | Threaded
Open this post in threaded view
|

Re: security - preferred way to make check_access_file happy?

Adam Thompson
In reply to this post by Stuart Henderson
On 2019-02-25 11:14, Stuart Henderson wrote:

> On 2019/02/25 09:13, Adam Thompson wrote:
>> > Use vipw to put 13 * in the password field
>> >
>> > From passwd(5)
>> > [...]
>> >  authentication, conventionally have 13 asterisks in the password field.
>>
>> Thank you!  Now that I know what I'm looking for, I can see the
>> relevant
>> code in security(8), too.
>>
>> I wonder if there's a way for ports to do that for me while calling
>> useradd?
>> Another rabbit hole to go down.
>>
>> Thanks again,
>> -Adam
>>
>
> It normally does already. Do you have an unusual "password" line in
> /etc/usermgmt.conf?

Nope.
Ugh, although I said ports does this often in my experience, the only
system/port I have right now where it's doing it is the RANCID package
on that dedicated VM.  I have two other VMs where I have manually
created single-purpose userids without passwords that also complain (one
for RT [not from ports], one for webhosting).
So it could just be that package; at least I can't demonstrate any
others right now.
-Adam

Reply | Threaded
Open this post in threaded view
|

Re: security - preferred way to make check_access_file happy?

Stuart Henderson
In reply to this post by Theo Buehler-3
On 2019/02/25 18:20, Theo Buehler wrote:

> On Mon, Feb 25, 2019 at 05:14:50PM +0000, Stuart Henderson wrote:
> > On 2019/02/25 09:13, Adam Thompson wrote:
> > > > Use vipw to put 13 * in the password field
> > > >
> > > > From passwd(5)
> > > > [...]
> > > >  authentication, conventionally have 13 asterisks in the password field.
> > >
> > > Thank you!  Now that I know what I'm looking for, I can see the relevant
> > > code in security(8), too.
> > >
> > > I wonder if there's a way for ports to do that for me while calling useradd?
> > > Another rabbit hole to go down.
> > >
> > > Thanks again,
> > > -Adam
> > >
> >
> > It normally does already. Do you have an unusual "password" line in /etc/usermgmt.conf?
>
> I think the user(8) behavior changed in that regard in user.c rev 1.112
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/user/user.c.diff?r1=1.111&r2=1.112
>
> @@ -1130,16 +1082,8 @@
>   warnx("Warning: home directory `%s' doesn't exist, and -m was"
>      " not specified", home);
>   }
> - if (up->u_password != NULL && valid_password_length(up->u_password)) {
> - (void) strlcpy(password, up->u_password, sizeof(password));
> - } else {
> - (void) memset(password, '*', DES_Len);
> - password[DES_Len] = 0;
> - if (up->u_password != NULL) {
> - warnx("Password `%s' is invalid: setting it to `%s'",
> - up->u_password, password);
> - }
> - }
> + (void) strlcpy(password, up->u_password ? up->u_password : "*",
> +    sizeof(password));
>   cc = snprintf(buf, sizeof(buf), "%s:%s:%u:%u:%s:%lld:%lld:%s:%s:%s\n",
>      login_name,
>      password,
>

Ah yes - I must have been looking at users from old installed
packages. Now I scroll down further I see them too..

Reply | Threaded
Open this post in threaded view
|

Re: security - preferred way to make check_access_file happy?

Ross L Richardson
In reply to this post by Solene Rapenne

> On 2019-02-26, at 02:01 , Solene Rapenne <[hidden email]> wrote:
> [...]
>
> Use vipw to put 13 * in the password field
> [...]

Or, FWIW, just:
        usermod -p '*************' user

Ross