[snap] Apparmor audit messages for calls to sched_setaffinity

This is not chromium-specific, those are audit messages emitted by apparmor (see https://gitlab.com/apparmor/apparmor/-/wikis/AppArmorAuditing for details).

Installing auditd might help.

Your rulesets are bad, it's not apparmor's fault.

The rulesets still don't explicitly forbid this syscall and it still gets massively logged into dmesg, making it totally unusable.

```
audit: type=1326 audit(1610482813.754:1835962): auid=1000 uid=1000 gid=1000 ses=4 pid=2201984 comm="chrome" exe="/snap/chromium/1444/usr/lib/chromium-browser/chrome" sig=0 arch=c000003e syscall=203 compat=0 ip=0x7f1190d36c7f code=0x50000
```

Current Chromium snap AppArmor profile needs fixing, this level of logging is not okay.

The relevant syscall is `sched_setaffinity`, which when used with a first argument of `0` is allowed in the default policy. Can someone who is experiencing this bug run an strace to determine what argument chromium is trying to use with sched_setaffinity ? We allow any sched_setaffinity arguments with the process-control interface, but if this denial is not breaking the application then perhaps it should just be silenced in the policy instead.

It doesn't break it visibly. I would prefer if it were allowed to set its affinity, but if that can't be done, silencing is a must. This is incredibly spammy.

> Can someone who is experiencing this bug run an strace to determine what argument chromium is trying to use with sched_setaffinity ?

I'm not sure how its possible to strace a snap container ran under a specific user. Could you provide the command?

snap run --strace chromium

[pid 1278591] sched_setaffinity(1278591, 128, [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226, 227, 228, 229, 230, 231, 232, 233, 234, 235, 236, 237, 238, 239, 240, 241, 242, 243, 244, 245, 246, 247, 248, 249, 250, 251, 252, 253, 254, 255, 256, 257, 258, 259, 260, 261, 262, 263, 264, 265, 266, 267, 268, 269, 270, 271, 272, 273, 274, 275, 276, 277, 278, 279, 280, 281, 282, 283, 284, 285, 286, 287, 288, 289, 290, 291, 292, 293, 294, 295, 296, 297, 298, 299, 300, 301, 302, 303, 304, 305, 306, 307, 308, 309, 310, 311, 312, 313, 314, 315, 316, 317, 318, 319, 320, 321, 322, 323, 324, 325, 326, 327, 328, 329, 330, 331, 332, 333, 334, 335, 336, 337, 338, 339, 340, 341, 342, 343, 344, 345, 346, 347, 348, 349, 350, 351, 352, 353, 354, 355, 356, 357, 358, 359, 360, 361, 362, 363, 364, 365, 366, 367, 368, 369, 370, 371, 372, 373, 374, 375, 376, 377, 378, 379, 380, 381, 382, 383, 384, 385, 386, 387, 388, 389, 390, 391, 392, 393, 394, 395, 396, 397, 398, 399, 400, 401, 402, 403, 404, 405, 406, 407, 408, 409, 410, 411, 412, 413, 414, 415, 416, 417, 418, 419, 420, 421, 422, 423, 424, 425, 426, 427, 428, 429, 430, 431, 432, 433, 434, 435, 436, 437, 438, 439, 440, 441, 442, 443, 444, 445, 446, 447, 448, 449, 450, 451, 452, 453, 454, 455, 456, 457, 458, 459, 460, 461, 462, 463, 464, 465, 466, 467, 468, 469, 470, 471, 472, 473, 474, 475, 476, 477, 478, 479, 480, 481, 482, 483, 484, 485, 486, 487, 488, 489, 490, 491, 492, 493, 494, 495, 496, 497, 498, 499, 500, 501, 502, 503, 504, 505, 506, 507, 508, 509, 510, 511, 512, 513, 514, 515, 516, 517, 518, 519, 520, 521, 522, 523, 524, 525, 526, 527, 528, 529, 530, 531, 532, 533, 534, 535, 536, 537, 538, 539, 540, 541, 542, 543, 544, 545, 546, 547, 548, 549, 550, 551, 552, 553, 554, 555, 556, 557, 558, 559, 560, 561, 562, 563, 564, 565, 566, 567, 568, 569, 570, 571, 572, 573, 574, 575, 576, 577, 578, 579, 580, 581, 582, 583, 584, 585, 586, 587, 588, 589, 590, 591, 592, 593, 594, 595, 596, 597, 598, 599, 600, 601, 602, 603, 604, 605, 606, 607, 608, 609, 610, 611, 612, 613, 614, 615, 616, 617, 618, 619, 620, 621, 622, 623, 624, 625, 626, 627, 628, 629, 630, 631, 632, 633, 634, 635, 636, 637, 638, 639, 640, 641, 642, 643, 644, 645, 646, 647, 648, 649, 650, 651, 652...

[pid 1278569] sched_setaffinity(1278640, 128, [18, 19, 20, 21, 22, 23] <unfinished ...>
[pid 1278569] <... sched_setaffinity resumed>) = -1 EPERM (Operation not permitted)

So I did a bit of looking and it appears that Chromium only calls sched_setaffinity for it's renderer threads on Android (maybe?). I'm not super familiar with Chromium source code so it's a bit difficult for me to tell, but I tried playing videos etc. which might trigger some sort of rendering code and I couldn't reproduce the denial.

@avamander, do you have a reproducer for this?

I'm happy to allow chromium this access for browser-support with the allow-sandbox: true attribute as chromium uses it, as there are other more privileged system calls already allowed to Chromium through this interface and it appears to me that this system call may allow better performance on some specific devices with "big / little" architectures such as ARM, but I would like to see if anyone else can reproduce this and perhaps if Olivier can comment about Chromium's usage of sched_setaffinity...

If we can't determine what is causing the denial, then we can also deny/silence it in the policy so it stops filling up log messages.

> @avamander, do you have a reproducer for this?

I'm just using it on a Ryzen 9 3900x and Radeon R7 360. I have GPU acceleration enabled to the extent it is possible.

I see sched_setaffinity also used in base/cpu_affinity_posix.cc, so I doubt it's only beneficial on ARM.

Status changed to 'Confirmed' because the bug affects multiple users.

Ian is correct, all the explicit call sites for sched_setaffinity in chromium are android-specific.

I do see a handful of those audit messages in my logs when I start chromium, but it's far from spamming the logs. I wonder what is causing such a volume for Avamander. Which OS/version are you running the chromium snap on?

Ubuntu 20.04.1

It occurred to me that we don't actually currently have a way to silence seccomp denials, so instead I opted to open a PR allowing unrestricted sched_setaffinity with browser-sandbox: true @ https://github.com/snapcore/snapd/pull/9865.

Thanks for your patience.

I've marked the chromium bug as invalid since snapd now allows sched_setaffinity with browser-sandbox: true (see comment 16). I checked here with firefox and chromium (both snaps) and the only syscall=203 denial is unrelated:

$ journalctl -o cat -b-1 -k --grep syscall=203
audit: type=1326 audit(1666098873.038:90): auid=1000 uid=1000 gid=1000 ses=3 subj=? pid=3817 comm="snapd-desktop-i" exe="/snap/snapd-desktop-integration/14/bin/snapd-desktop-integration" sig=0 arch=c000003e syscall=203 compat=0 ip=0x7078b4388741 code=0x50000

Thanks Simon for confirming.