Page MenuHomeFreeBSD
Feed Advanced Search

Sep 12 2020

shivank added a comment to D26243: Add audit(4) support to NFS(v3).

Isn't audit_nfsarg_vnode1 the problem? You already know the path when you call AUDIT_ARG_UPATH1_VP, right?

Sep 12 2020, 7:43 AM · security, GSoC Students, Audit

Sep 11 2020

asomers added a comment to D26243: Add audit(4) support to NFS(v3).
In D26243#587132, @mjg wrote:

Audit support for regular lookup starts with AUDIT_ARG_UPATH1_VP/AUDIT_ARG_UPATH2_VP without any vnodes locked. Later on visited vnodes get added with AUDIT_ARG_VNODE1/AUDIT_ARG_VNODE2 which only performs VOP_GETATTR (i.e. does *NOT* resolve any paths). Your code should follow the same scheme.

As you can see path resolving routines can take vnode locks on their own (modulo the smr case). This means they can't be called with locked vnodes to begin with, as otherwise you risk violating global lock ordering and consequently deadlocking the kernel.

The VOP_ISLOCKED routine is not entirely legal to call if you don't hold the lock. The name is perhaps misleading, but it can only reliably tell you that you have an exclusive lock or that *SOMEONE* has a shared lock (and it may be you). Or to put it differently, if you don't have the vnode locked but someone else has it shared locked, you will get non-0 and that's how you get the panic. Regardless of this problem, adding the call reduces performance and most notably suggests a bug on its own.

So the question is why are you calling here with any vnodes locked.

I wish to audit the canonical path of the file requested by the NFS clients. The requested path from the client is extracted in the NFS server using nfsrv_parsename, but the vnode is locked in some NFS services. I thought of unlocking/relocking of vnode for path audit but Rick advised not to. That's why I had to call this locked vnode.

Thanks for your question which made me rethink the problem from scratch and I got a new idea for auditing path.

Hi @rmacklem and @asomers, if I use nfsvno_namei to get the canonical path for the client, I will not the need the AUDIT_ARG_UPATH1_VP.which will save me from all the trouble of passing locked vnode to vn_fullpath_global. Please provide your opinion on the same.

Sep 11 2020, 11:11 PM · security, GSoC Students, Audit
shivank added a comment to D26243: Add audit(4) support to NFS(v3).
In D26243#587132, @mjg wrote:

Audit support for regular lookup starts with AUDIT_ARG_UPATH1_VP/AUDIT_ARG_UPATH2_VP without any vnodes locked. Later on visited vnodes get added with AUDIT_ARG_VNODE1/AUDIT_ARG_VNODE2 which only performs VOP_GETATTR (i.e. does *NOT* resolve any paths). Your code should follow the same scheme.

As you can see path resolving routines can take vnode locks on their own (modulo the smr case). This means they can't be called with locked vnodes to begin with, as otherwise you risk violating global lock ordering and consequently deadlocking the kernel.

The VOP_ISLOCKED routine is not entirely legal to call if you don't hold the lock. The name is perhaps misleading, but it can only reliably tell you that you have an exclusive lock or that *SOMEONE* has a shared lock (and it may be you). Or to put it differently, if you don't have the vnode locked but someone else has it shared locked, you will get non-0 and that's how you get the panic. Regardless of this problem, adding the call reduces performance and most notably suggests a bug on its own.

So the question is why are you calling here with any vnodes locked.

Sep 11 2020, 11:10 AM · security, GSoC Students, Audit
shivank added a reviewer for D26243: Add audit(4) support to NFS(v3): mjg.
Sep 11 2020, 4:45 AM · security, GSoC Students, Audit
mjg added a comment to D26243: Add audit(4) support to NFS(v3).

Audit support for regular lookup starts with AUDIT_ARG_UPATH1_VP/AUDIT_ARG_UPATH2_VP without any vnodes locked. Later on visited vnodes get added with AUDIT_ARG_VNODE1/AUDIT_ARG_VNODE2 which only performs VOP_GETATTR (i.e. does *NOT* resolve any paths). Your code should follow the same scheme.

Sep 11 2020, 12:40 AM · security, GSoC Students, Audit

Sep 10 2020

shivank updated subscribers of D26243: Add audit(4) support to NFS(v3).

I feel vfs_cache.c changes for making vn_fullpath_global work for optionally locked vnode are causing the trouble. Though I'm not sure what's the problem. I request Mateusz Guzik, @mjg to have a look at my vfs_cache.c changes. I would be grateful for your time.

Sep 10 2020, 3:05 PM · security, GSoC Students, Audit

Sep 7 2020

asomers requested changes to D26243: Add audit(4) support to NFS(v3).

The new code looks better. But grrr, there are two big problems:

  1. It doesn't compile due to some recent changes on head. I suggest the following:
    • Remove the <rpc/rpc.h>, <sys/mount.h>, and <fs/nfs/*> includes from audit.h. In addition to fixing the compile failure, it's generally not recommended to include headers from other headers. Sometimes it's necessary, but it also causes header pollution, and slow build times. Instead of including those files, just forward declare struct nfsrv_descript; and struct kaudit_record;.
    • Add `<netinet/in.h>, <rpc/rpc.h>, <fs/nfs/nfsdport.h>, <fs/nfs/nfsproto.h>, and <fs/nfs/nfs.h> to audit_bsm_db.c
    • Add <rpc/rpc.h>, <fs/nfs/nfsport.h>, <fs/nfs/nfsproto.h>, and <fs/nfs/nfs.h> to audit.c
Sep 7 2020, 5:30 PM · security, GSoC Students, Audit
shivank updated the diff for D26243: Add audit(4) support to NFS(v3).
  • merge vn_fullpath_any and vn_vptocnp with their locked counterpart to work for optionally locked vnodes.
Sep 7 2020, 10:52 AM · security, GSoC Students, Audit

Sep 6 2020

asomers added inline comments to D26243: Add audit(4) support to NFS(v3).
Sep 6 2020, 9:05 PM · security, GSoC Students, Audit

Aug 31 2020

shivank abandoned D25869: Add audit(4) support to NFS(v3).

I created a new review - D26243. Sorry for the trouble.

Aug 31 2020, 5:06 AM · security, GSoC Students, Audit
shivank added a comment to D26243: Add audit(4) support to NFS(v3).

It was earlier being reviewed on D25869. But due to change of base revision, It was showing changes which were not mine. So, I created a new review here.

Aug 31 2020, 5:03 AM · security, GSoC Students, Audit
shivank requested review of D26243: Add audit(4) support to NFS(v3).
Aug 31 2020, 4:57 AM · security, GSoC Students, Audit

Aug 30 2020

asomers added a comment to D25869: Add audit(4) support to NFS(v3).

It looks like your most recent change rebased the base revision. That makes it very hard to see which changes are from you and which aren't. Could you please either un-rebase it or, if that's not possible, open a new review?

Ohh, Sorry! I didn't thought pulling HEAD changes will create this side-effect in revision
I think I would open a new review as going back will have conflicting changes again. Should I abandon this while creating a new one??

Aug 30 2020, 8:58 PM · security, GSoC Students, Audit
shivank added a comment to D25869: Add audit(4) support to NFS(v3).

It looks like your most recent change rebased the base revision. That makes it very hard to see which changes are from you and which aren't. Could you please either un-rebase it or, if that's not possible, open a new review?

Aug 30 2020, 5:42 PM · security, GSoC Students, Audit
asomers added a comment to D25869: Add audit(4) support to NFS(v3).

Using two completely separate functions reduces the scope of error. Also prevent any mutation to the current code path for not locked vnodes, while allowing it to work for locked vnodes.

Aug 30 2020, 2:54 PM · security, GSoC Students, Audit

Aug 28 2020

shivank added a comment to D25869: Add audit(4) support to NFS(v3).
  • updated sys/kern/vfs_cache.c to reduce code duplication with vn_fullpath_dir
  • some trivial changes
Aug 28 2020, 4:18 PM · security, GSoC Students, Audit
shivank updated the diff for D25869: Add audit(4) support to NFS(v3).
Aug 28 2020, 4:04 PM · security, GSoC Students, Audit

Aug 20 2020

shivank added a comment to D25869: Add audit(4) support to NFS(v3).

Regarding code duplication in vn_fullpath_dir_locked:
I modified vn_fullpath_dir(and removed vn_fullpath_dir_locked) for optionally locked vnode here in git commit: https://github.com/shivankgarg98/freebsd/commit/418c1c2a6de9989fe7a541f6111ee2c3f2786c7b
It works fine NFSv4=3 case but somehow breaks nfsrvd_open to result in an error.{and hence can't open/create a regular file from client}.
Using two completely separate functions reduces the scope of error. Also prevent any mutation to the current code path for not locked vnodes, while allowing it to work for locked vnodes.

Aug 20 2020, 8:34 PM · security, GSoC Students, Audit
shivank updated the diff for D25869: Add audit(4) support to NFS(v3).

follow-up on suggested changes.

Aug 20 2020, 7:21 PM · security, GSoC Students, Audit

Aug 19 2020

asomers added a comment to D25869: Add audit(4) support to NFS(v3).

This is a much better locking strategy. However, there's a lot of duplicated code. Could you maybe combine the _locked with the original functions, so there wouldn't be so much duplication?

Aug 19 2020, 2:43 AM · security, GSoC Students, Audit

Aug 4 2020

shivank updated the diff for D25869: Add audit(4) support to NFS(v3).

removing unlocking/relocking implementation for vnode for auditing path, instead, define separate functions in vfs_cache.c for locked vnode as argument.

Aug 4 2020, 6:09 PM · security, GSoC Students, Audit

Jul 30 2020

shivank updated the diff for D25869: Add audit(4) support to NFS(v3).
Jul 30 2020, 7:17 PM · security, GSoC Students, Audit
shivank added a comment to D25869: Add audit(4) support to NFS(v3).

Thanks for all suggestions. I have incorporated them into my code. There is just a directory vnode unlocking/relocking issue not done yet.

Jul 30 2020, 7:08 PM · security, GSoC Students, Audit
rmacklem added a comment to D25869: Add audit(4) support to NFS(v3).

In summary, locking and unlocking vnodes in this code is dangerous
and I am not in a position to make sure what you do is safe.

Jul 30 2020, 1:05 AM · security, GSoC Students, Audit

Jul 29 2020

asomers added inline comments to D25869: Add audit(4) support to NFS(v3).
Jul 29 2020, 7:19 PM · security, GSoC Students, Audit
shivank added inline comments to D25869: Add audit(4) support to NFS(v3).
Jul 29 2020, 6:38 PM · security, GSoC Students, Audit
shivank updated the diff for D25869: Add audit(4) support to NFS(v3).

follow up on changes suggested by asomers@

Jul 29 2020, 6:35 PM · security, GSoC Students, Audit
asomers added inline comments to D25869: Add audit(4) support to NFS(v3).
Jul 29 2020, 12:10 AM · security, GSoC Students, Audit

Jul 28 2020

shivank requested review of D25869: Add audit(4) support to NFS(v3).
Jul 28 2020, 8:25 PM · security, GSoC Students, Audit

Jun 27 2019

cperciva added inline comments to D20780: Add support for getting early entropy from the UEFI RNG protocol.
Jun 27 2019, 11:59 PM · security, arm64
D20780: Add support for getting early entropy from the UEFI RNG protocol now requires changes to proceed.
Jun 27 2019, 10:22 PM · security, arm64
bcran added inline comments to D20780: Add support for getting early entropy from the UEFI RNG protocol.
Jun 27 2019, 9:05 PM · security, arm64
cem added inline comments to D20780: Add support for getting early entropy from the UEFI RNG protocol.
Jun 27 2019, 7:16 PM · security, arm64
greg_unrelenting.technology added inline comments to D20780: Add support for getting early entropy from the UEFI RNG protocol.
Jun 27 2019, 6:31 PM · security, arm64
D20780: Add support for getting early entropy from the UEFI RNG protocol is now accepted and ready to land.

Presuming all the testing works :-)

Jun 27 2019, 6:26 PM · security, arm64
cperciva added inline comments to D20780: Add support for getting early entropy from the UEFI RNG protocol.
Jun 27 2019, 4:58 PM · security, arm64
emaste updated subscribers of D20780: Add support for getting early entropy from the UEFI RNG protocol.
Jun 27 2019, 3:02 PM · security, arm64
cem updated subscribers of D20780: Add support for getting early entropy from the UEFI RNG protocol.
Jun 27 2019, 3:01 PM · security, arm64
greg_unrelenting.technology created D20780: Add support for getting early entropy from the UEFI RNG protocol.
Jun 27 2019, 2:39 PM · security, arm64

May 11 2019

oshogbo added a member for security: oshogbo.
May 11 2019, 1:33 PM

Apr 1 2019

royce_techsolvency.com added a comment to D15713: Bug 182518 - [login.conf] Better Password Hashes .

Minor comment - results of real-world testing of cracking resistance, both for the 11.x defaults and for those proposed by D15713.

Apr 1 2019, 9:36 PM · security

Sep 1 2018

jmg added a comment to D15713: Bug 182518 - [login.conf] Better Password Hashes .

All comments are minor.

Sep 1 2018, 6:40 PM · security

Aug 20 2018

ler added a comment to D15713: Bug 182518 - [login.conf] Better Password Hashes .

Any chance of this being moved forward in time for the 12 branch?

Aug 20 2018, 12:32 AM · security

Aug 16 2018

482254ac_razorfever.net added inline comments to D15713: Bug 182518 - [login.conf] Better Password Hashes .
Aug 16 2018, 10:05 AM · security
482254ac_razorfever.net updated the diff for D15713: Bug 182518 - [login.conf] Better Password Hashes .

I'm hopeful that this fixes style, and other suggestions from delphij.

Aug 16 2018, 10:00 AM · security

Aug 9 2018

482254ac_razorfever.net updated the diff for D15713: Bug 182518 - [login.conf] Better Password Hashes .

Updates remaining man styles.

Aug 9 2018, 10:22 AM · security

Aug 3 2018

482254ac_razorfever.net added inline comments to D15713: Bug 182518 - [login.conf] Better Password Hashes .
Aug 3 2018, 8:33 PM · security
delphij added inline comments to D15713: Bug 182518 - [login.conf] Better Password Hashes .
Aug 3 2018, 5:58 PM · security
emaste added a comment to D15713: Bug 182518 - [login.conf] Better Password Hashes .

In fairness, this example pre-dates the crypt_r in FreeBSD by 4+ years.

Aug 3 2018, 2:26 PM · security
482254ac_razorfever.net added inline comments to D15713: Bug 182518 - [login.conf] Better Password Hashes .
Aug 3 2018, 10:35 AM · security

Aug 2 2018

482254ac_razorfever.net added inline comments to D15713: Bug 182518 - [login.conf] Better Password Hashes .
Aug 2 2018, 10:33 AM · security

Aug 1 2018

delphij requested changes to D15713: Bug 182518 - [login.conf] Better Password Hashes .
Aug 1 2018, 2:51 AM · security

Jul 31 2018

482254ac_razorfever.net updated the diff for D15713: Bug 182518 - [login.conf] Better Password Hashes .

This update covers the linting, and simplified example code in the libcrypt manpage.

Jul 31 2018, 8:32 PM · security

Jul 28 2018

delphij requested changes to D15713: Bug 182518 - [login.conf] Better Password Hashes .

Could you please split the proposed change to smaller pieces, so it would be easier to review?

Jul 28 2018, 12:10 AM · security

Jul 27 2018

allanjude added reviewers for D15713: Bug 182518 - [login.conf] Better Password Hashes : delphij, jmg.
Jul 27 2018, 10:58 PM · security

Jul 16 2018

bcr added a comment to D15713: Bug 182518 - [login.conf] Better Password Hashes .

There are a bunch of style issues with crypt.3. Can you run "mandoc -Tlint" and textproc/igor (from ports/packages) on it? It should give you some feedback where the problems are. For example, man pages need a line break after a sentence stop.

Jul 16 2018, 7:54 PM · security

Jun 11 2018

allanjude added a reviewer for D15713: Bug 182518 - [login.conf] Better Password Hashes : allanjude.
Jun 11 2018, 3:03 AM · security

Jun 10 2018

482254ac_razorfever.net updated the diff for D15713: Bug 182518 - [login.conf] Better Password Hashes .

Fix loop always executing twice (in pw+pam_unix), with leaky memory.

Jun 10 2018, 12:55 PM · security

Jun 9 2018

482254ac_razorfever.net updated the diff for D15713: Bug 182518 - [login.conf] Better Password Hashes .

Fix accent on David's name, per imp feedback.

Jun 9 2018, 9:26 PM · security
imp added inline comments to D15713: Bug 182518 - [login.conf] Better Password Hashes .
Jun 9 2018, 2:12 PM · security
482254ac_razorfever.net updated the summary of D15713: Bug 182518 - [login.conf] Better Password Hashes .
Jun 9 2018, 4:03 AM · security
482254ac_razorfever.net created D15713: Bug 182518 - [login.conf] Better Password Hashes .
Jun 9 2018, 4:02 AM · security

May 8 2018

mateusz_serveraptor.com added a watcher for security: mateusz_serveraptor.com.
May 8 2018, 8:30 PM

Mar 13 2018

badfilemagic_gmail.com removed a watcher for security: badfilemagic_gmail.com.
Mar 13 2018, 4:23 PM

Jul 7 2017

tz closed D11515: lang/php70: Update to 7.0.21 by committing rP445231: Update PHP 7 from 7.0.20 to 7.0.21.
Jul 7 2017, 9:58 AM · security
tz accepted D11515: lang/php70: Update to 7.0.21.
Jul 7 2017, 9:57 AM · security
tz closed D11516: lang/php71: Update to 7.1.7.

Was already committed in r445228.

Jul 7 2017, 9:46 AM · security
tz accepted D11516: lang/php71: Update to 7.1.7.
Jul 7 2017, 9:45 AM · security
i.dani_outlook.com created D11516: lang/php71: Update to 7.1.7.
Jul 7 2017, 9:37 AM · security
i.dani_outlook.com created D11515: lang/php70: Update to 7.0.21.
Jul 7 2017, 9:34 AM · security

Jun 30 2017

lwhsu changed the visibility for security.
Jun 30 2017, 6:40 PM

Jun 11 2017

badfilemagic_gmail.com added a watcher for security: badfilemagic_gmail.com.
Jun 11 2017, 3:31 PM

Mar 22 2016

lattera-gmail.com added a watcher for security: lattera-gmail.com.
Mar 22 2016, 12:22 AM

Jan 19 2016

bapt closed D4771: libfetch: test for /etc/ssl/cert.pem existence to avoid masking SSL_CA_CERT_PATH.
Jan 19 2016, 3:04 PM · security
bapt accepted D4771: libfetch: test for /etc/ssl/cert.pem existence to avoid masking SSL_CA_CERT_PATH.

As been committed as rS294326 (discussed with des)

Jan 19 2016, 3:04 PM · security

Jan 4 2016

john_saltant.com updated the test plan for D4771: libfetch: test for /etc/ssl/cert.pem existence to avoid masking SSL_CA_CERT_PATH.
Jan 4 2016, 12:55 PM · security

Jan 3 2016

john_saltant.com retitled D4771: libfetch: test for /etc/ssl/cert.pem existence to avoid masking SSL_CA_CERT_PATH from to libfetch: test for /etc/ssl/cert.pem existence to avoid masking SSL_CA_CERT_PATH.
Jan 3 2016, 11:44 PM · security

Oct 22 2015

koobs added a comment to D3463: Adopt higher level of stack protection..

Apologies, I intended to Commandeer -> Close.

Oct 22 2015, 9:57 AM · security
koobs commandeered D3463: Adopt higher level of stack protection..
Oct 22 2015, 9:56 AM · security

Oct 8 2015

pfg abandoned D3463: Adopt higher level of stack protection..

This is already in the tree (apparently no one approved it though).

Oct 8 2015, 3:12 PM · security

Oct 4 2015

pfg added a comment to D3463: Adopt higher level of stack protection..

Committed as r288669.

Oct 4 2015, 7:11 PM · security
pfg updated the test plan for D3463: Adopt higher level of stack protection..
Oct 4 2015, 7:10 PM · security

Oct 3 2015

pfg added a comment to D3463: Adopt higher level of stack protection..

Results from exp-run (PR 2013394) are out:


Exp-run results on head i386:
http://package23.nyi.freebsd.org/jail.html?mastername=headi386PR203394-default

Oct 3 2015, 5:56 PM · security

Sep 28 2015

pfg added a comment to D3463: Adopt higher level of stack protection..

Peter Holm has kindly provided some testing:

Sep 28 2015, 2:37 PM · security

Sep 26 2015

pfg added a comment to D3463: Adopt higher level of stack protection..

...

Will it be possible that you can provide some basic test data, for instance, a few world stone runs on memory disk, and see how exactly the impact would be? It would be easier to convince people when you have first hand data, and although we know others have already do some testing, it's important to know if the same applies on FreeBSD because it's likely that the experiments were not on FreeBSD, and the result may be different.

Sep 26 2015, 3:17 AM · security

Sep 25 2015

delphij added a comment to D3463: Adopt higher level of stack protection..

I'll patch my laptop and have started a clean build so I'll see if there would be visible performance/other impact after running with it for a few days.

Sep 25 2015, 7:58 PM · security

Aug 29 2015

pfg added a comment to D3463: Adopt higher level of stack protection..
Aug 29 2015, 7:53 PM · security

Aug 28 2015

pfg added a comment to D3463: Adopt higher level of stack protection..
Aug 28 2015, 2:57 PM · security

Aug 27 2015

bdrewery added a comment to D3463: Adopt higher level of stack protection..

+1

Aug 27 2015, 6:22 PM · security
pfg added a reviewer for D3463: Adopt higher level of stack protection.: jlh.
Aug 27 2015, 4:07 PM · security

Aug 23 2015

pfg added a comment to D3463: Adopt higher level of stack protection..
In D3463#70669, @imp wrote:

What's the performance impact?

Aug 23 2015, 3:26 PM · security
op added a comment to D3463: Adopt higher level of stack protection..

We should investigate that the -fstack-protector-strong triggers the same as -fstack-protector-all:

Aug 23 2015, 12:07 PM · security
op added a comment to D3463: Adopt higher level of stack protection..
Aug 23 2015, 12:03 PM · security
imp requested changes to D3463: Adopt higher level of stack protection..

What's the performance impact?

Aug 23 2015, 3:25 AM · security
pfg added a reviewer for D3463: Adopt higher level of stack protection.: secteam.
Aug 23 2015, 3:22 AM · security

Jul 15 2015

jmg added a member for security: jmg.
Jul 15 2015, 5:44 AM

Jul 12 2015

markm added a member for security: markm.
Jul 12 2015, 6:32 PM