1555 |
will not be overwritten by TOMOYO Linux kernels. |
will not be overwritten by TOMOYO Linux kernels. |
1556 |
|
|
1557 |
Version 1.6.4 2008/09/03 Minor update release. |
Version 1.6.4 2008/09/03 Minor update release. |
1558 |
|
|
1559 |
|
Fix 2008/09/09 |
1560 |
|
|
1561 |
|
@ Add "try again" response to "delayed enforcing" mode. |
1562 |
|
|
1563 |
|
To be able to handle pathname changes caused by software updates, |
1564 |
|
"delayed enforcing" mode was introduced. It allows administrator to |
1565 |
|
grant access requests which are about to be rejected by the kernel. |
1566 |
|
|
1567 |
|
To be able to handle pathname changes caused by software updates better, |
1568 |
|
I introduced "try again" response. As "delayed enforcing" mode sleeps |
1569 |
|
a process which violated policy, administrator can update policy while |
1570 |
|
the process is sleeping. This "try again" response allows administrator |
1571 |
|
to restart policy checks from the beginning after updating policy. |
1572 |
|
|
1573 |
|
Fix 2008/09/11 |
1574 |
|
|
1575 |
|
@ Remember whether the process is allowed to write to /proc/ccs/ interface. |
1576 |
|
|
1577 |
|
Since programs for manipulating policy (e.g. ccs-queryd ) are installed |
1578 |
|
in the form of RPM/DEB packages, these programs lose the original |
1579 |
|
pathnames when they are updated by the package manager. The package |
1580 |
|
manager renames these programs before deleting these programs so that |
1581 |
|
the package manager can rollback the operation. |
1582 |
|
This causes a problem when the programs are listed into /proc/ccs/manager |
1583 |
|
using pathnames, as the programs will no longer be allowed to write to |
1584 |
|
/proc/ccs/ interface while the process of old version of the program is |
1585 |
|
alive. |
1586 |
|
|
1587 |
|
To solve this problem, I modified to remember the fact that the process |
1588 |
|
is once allowed to write to /proc/ccs/ interface until the process |
1589 |
|
attempts to execute a different program. |
1590 |
|
This change makes it impossible to revoke permission to write to |
1591 |
|
/proc/ccs/ interface without killing the process, but it will be better |
1592 |
|
than nonfunctioning ccs-queryd program. |
1593 |
|
|
1594 |
|
Fix 2008/09/19 |
1595 |
|
|
1596 |
|
@ Allow selecting a domain by PID. |
1597 |
|
|
1598 |
|
Sometimes we want to know what ACLs are given to specific PID, but |
1599 |
|
finding a domainname for that PID from /proc/ccs/.process_status and |
1600 |
|
reading ACLs from /proc/ccs/domain_policy by the domainname is very slow. |
1601 |
|
Thus, I modified /proc/ccs/domain_policy to allow selecting a domain by |
1602 |
|
PID. For example, to read domain ACL of current process from bash, |
1603 |
|
run as follows. |
1604 |
|
|
1605 |
|
# exec 100<>/proc/ccs/domain_policy |
1606 |
|
# echo select $$ >&100 |
1607 |
|
# while read -u 100; do echo $REPLY; done |
1608 |
|
|
1609 |
|
If a domain is once selected by PID, reading /proc/ccs/domain_policy will |
1610 |
|
print only that domain if that PID exists or print nothing otherwise. |
1611 |
|
|
1612 |
|
@ Disallow concurrent /proc/ccs/ access using the same file descriptor. |
1613 |
|
|
1614 |
|
Until now, one process can read() from /proc/ccs/ while other process |
1615 |
|
that shares the file descriptor can write() to /proc/ccs/ . |
1616 |
|
But to implement "Allow selecting a domain by PID" feature, I disabled |
1617 |
|
concurrent read()/write() because the feature need to modify read buffer |
1618 |
|
while writing. |