1. Decentralized Information Flow Control
Kavya Jha
November 3rd, 2017
CMPS 223-Advanced Security (Fall 2017)

2. What is DIFC? Why do we need it?
MAC vs SeLinux & Trusted BSD vs TightLip vs HiStar & Asbestos vs Jif
Why Flume?
Tags, Labels, Capability
Decentralized privilege
Safe Label Changes/ Safe Messages
Endpoint Abstraction (Readable safe, Writable safe, R/W safe)
IPC in Flume
User-level implementation (Confined vs Unconfined processes/Spawn/TCB)
Persistence (Files, Metadata, Persistent Privileges, Groups, Setlabel)
MoinMoin Wiki vs FlumeWiki
Canvas Questions

3. What is DIFC? Why do we need it?
Modern applications grow in size and complexity and depend on 3rd party S/W.
Gives authority not to a central entity but to multiple processes as regards access control and information flow.
Privacy and DIFC: allows untrusted S/W to compute with private data while trusted security code controls the release of that data.
Integrity and DIFC: allows trusted code to protect untrusted S/W from unexpected malicious inputs.
Ultimately, only a fault in the trusted security code can lead to security violations. Hence, it is kept small and isolated.
Trusted processes: Aware of DIFC; set up privacy and integrity controls that constraint untrusted processes.
Untrusted processes: Do most of the computations; constrained by DIFC controls; might not know that.

4. MAC vs SeLinux and Trusted BSD vs TightLip vs HiStar vs Asbestos vs Jif
MAC: Security policies are mandatory and do not depend on the application writer. DIFC gives authority to individual applications.
SeLinux and Trusted BSD: Modify MAC but do not allow untrusted applications to define and update new security policies.
TightLip: Tags its private data that cannot leave the system through untrusted processes.
HiStar and Asbestos: allows safe mix of private data and security policies, support multiple security classes, kernel-based, combines mechanisms for privacy, integrity, authentication and declassification. Flume eliminates them. (Kernel improvements and new H/W support issues)
Jif: Closest to Flume, language-based, control is finer than Flume (individual functions rather than an entire process, needs rewriting)

5. Why Flume?
Gives authority to individual processes, hence, works at the granularity of OS processes.
Existing DIFC systems operate as PL abstractions and have no control over application development.
Very similar to centralized IFC with extensions for DIFC.
RM is at the user level and because of this user-level implementation, programmers can secure existing applications and build new ones.
Isolated trusted processes have the privilege to selectively violate classical IFC by declassifying/endorsing data.
This privilege is distributed among the trusted processes based on the application policy, making the IFC decentralized.

6. Tags/Labels/Capability
Flume uses Tags and Labels to track data as it flows through the system.
𝓣 is a set of opaque tokens calls tags. Labels belong to 𝓣.
t ∈ 𝓣: Processes associate each tag t with some secrecy or integrity label (Sp for secrecy and Ip for integrity).

7. If t ∈ Sp , then p has read some private data tagged with t
Label Sp
If t1 , t2 , t3 , ∈ Sp , then independent consent for each tag to publicly reveal data required
Process p
Label Ip
If t ∈ Ip , then every input to p has been endorsed as having integrity for t.

10. b a p

11. b a
PUBLIC WEBSITE

12. Secrecy:
If p reads Bob’s secret data, b ∈ Sp.
p with b ∈ Sp can only write to a process q with b ∈ Sq.
p cannot remove b from Sp.
p with b ∈ Sp cannot transmit information over an uncontrolled channel.
If these 4 conditions are met, then information from Bob to the untrusted process p won’t leak.
A similar condition set could be formed for Integrity as well.

13. Decentralized Privilege
Flume represents privilege using 2 capabilities per tag, t: t+ , t-.
Capability set Op , global capability set O ( O ∈ Op for all p).
Process p 1
Process p 2
Process p 3
Op : t +
Sp : { }
Ip : { }
Op : t -
Sp : { }
Ip : { }
Op : t +, t -
Sp : { }
Ip : { }

14. Use of Tags
Export Protection: can maintain secrecy of private data. A tag b can mark some private data. b+ is added to O but only trusted processes allocating these capabilities get b- (right to declassify).
Read Protection: allocate a tag t but do not add its read/write capabilities to O. So, no one else can see what capabilities the process possesses. Data leak is prevented.
Integrity Protection: certifier allocates tag v. v - is added to O. Any process p can remove v from Ip but only the certifier has v + (right to endorse).

15. Safe Label Changes/Safe Messages
Only process p can change Sp and Ip and the request for change is made explicitly.
Other models do it as and when messages are received and implicit label changes are converted into covert channels.
According to Definition 2, label change is safe only if
{L′ −L} + ∪ {L−L′} − ⊆ Op
Flume restricts communication among unprivileged processes. p can send a message to q only if: Sp ⊆ Sq and Iq ⊆ Ip.
Sp ⊆ Sq means that q can read from p but cannot write into p. So, privacy is maintained at q and declassification happens at p.
Iq ⊆ Ip means that p can read from q but cannot write into q. So, it it cannot endorse a data as q -high integrity.

16. Sp − Dp ⊆ Sq ∪ Dq and Iq − Dq ⊆ Ip ∪ Dp
7. While sending data, Sp - Dp lowers the secrecy and Ip ∪ Dp pushes the integrity up.
8. While receiving data, Sp ∪ Dp increases secrecy and Ip - Dp lowers integrity.
Definition 3: For a message from p to q to be safe,
Sp − Dp ⊆ Sq ∪ Dq and Iq − Dq ⊆ Ip ∪ Dp
9. Sq ∪ Dq (secrecy high) can read from Sp − Dp (secrecy low) but can’t write into it.
10. Ip ∪ Dp (integrity high) can read from Iq − Dq (integrity low) but can’t write into it.
11. For processes with no Dual Privilege, Dp = Dq = { }, Definition 3 translates to centralized IFC for safe flows.

17. 12. Any data sink/source outside of Flume is seen as an unprivileged process x with permanently empty labels Sx = Ix = { }.
13. So, a process p can write into x if it reduces its secrecy label to { } and Sp ⊆ Sx and can read from x if it reduces its integrity label to { }, Ix ⊆ Ip .

18. Endpoint Abstraction (Readable Safe vs Writable Safe vs R/W Safe)
Flume applies DIFC to Unix file descriptors for communication. It assigns an endpoint to each descriptor (defaults to process’s labels).
A process p can adjust the labels on an endpoint so all the information flow is controlled by these endpoints. Once this is configured properly, IPC is reliable.
Endpoints make declassification/endorsement decisions explicit (Mark the endpoints).
Sends (Declassification)
Privileged Process e1 f1 e2 f2
Receives (Endorsement)

19. 4. A readable endpoint e is safe iff (Se−Sp)∪(Ip −Ie) ⊆ Dp.
So, Snew = Se (cannot declassify Sp’s information which isn’t in Se).
5. A writable endpoint e is safe iff (Sp −Se)∪(Ie −Ip) ⊆ Dp.
So, Inew = Ip (can read high integrity data and push it to Ip).
6. A read/write endpoint is safe iff it meets both requirements.
7. Message M from endpoint e1 to e2 is safe iff e1 is writable and e2 is readable (same for processes).

20. IPC in Flume

21. User-level Implementation (Confined vs Unconfined processes/Spawn/TCB)
Portability
Easier Implementation
Correctness because Flume doesn’t destabilize the kernel
Decreased performance
Less access to kernel data structure. This makes the user exposed semantics more restrictive than DIFC.

22. Flume’s Linux implementation runs a small component in the kernel: an LSM implements Flume’s system call interposition.
Reference Monitor keeps track of each process’s labels and authorizes/denies it to change labels. This depends on (a) Spawners (2) Remote Tag Registry (3) User space file servers.
C library is aware of Flume and redirects all system calls to RM.
Processes communicate with RM via RPCs sent over a control socket.

23. 5. Processes on a system running Flume are of 2 types: Confined and Unconfined.
6. By default, processes are unconfined and have empty labels and empty non-global ownership. They behave as any out-of-Flume entities, conforming to regular Unix access control check.
7. For confined processes, RM controls the initial conditions and system calls. LSM ensures that this process cannot directly issue a system call. (Direct, Forwarded, Forbidden)
8. RM has complete knowledge of the processes and its resources.
9. Spawning is used to create new confined processes out of confined/unconfined processes. If the parent process is confined, it cannot fork and hence, cannot share pipes and sockets with its child process. (Flume_pipe, Flume_socketpair)

24. 10. Flume_pipe and Flume_socketpair return a single file descriptor and a random 64- bit pipe token which the parent process receives and communicates to the child process, which it sends to the RM that returns a file descriptor.

25. Sends the spawner request to the spawner process Spawner Process
Reference Monitor
Sends the spawner request to the spawner process
Spawner Process
Calls Fork
Fork
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Duis sit amet odio vel purus bibendum luctus. Morbi iaculis dapibus tristique. In hac habitasse platea dictumst. Mauris convallis quam at. Morbi iaculis dapibus tristique.

26. Spawner Process
Enables Flume’s LSM policy, performs Setlabel manipulations,
Invokes Flume’s permission checks.
File Descriptors
All open file descriptors are closed except for its control socket and those opened during permission checks.
Tokens
File descriptors are claimed by tokens.
Exec
Calls exec.

27. During exec call, LSM disallows all direct access to file systems by confined processes. When a child calls exec, LSm allows access to directories opened during permission checks. After exec call, all directories are closed and future access is denied.
Confined processed always run as unprivileged users. If an adversary had to take over a confined process, it could only issue those system calls allowed by the Flume LSM.
All other system interactions happen through RM and are subject to Flume’s restrictions.

28. Persistence (Files, Metadata, Persistent Privileges, Groups, Setlabel)
Flume provides persistence for capabilities and file labels (not to render data permanently unreadable/unwritable). It does so with the help of central tag registry.
Instead of some trusted servers directly collecting capabilities, a principal server owns a group G containing those capabilities it uses for declassification. Owning a capability for G implies owning all capabilities contained in G.
Setlabel is a facility which launches the declassifier.
A set label file isn’t allowed to be read. If a process’s label allows it read operation, it asks the RM to spawn the file.

29. MoinMoin Wiki vs FlumeWiki
MoinMoin Wiki is a wen publishing system that allows web clients to read and modify server-hosted pages.
It is designed to share documents between users and each page has its ACL that governs which users/groups can have access to it or can modify it.
ACL isn’t too secure. Approx. 91k LOC, 41 read checks and 19 write checks. It is easy to omit an ACL check. The codebase is huge. Hence, open to remote exploitation.
Supports plug-ins and buggy plug-ins can violate Moin’s ACL policies.
FlumeWiki tries to isolate the security module and leave the rest of Moin almost unchanged.
This reduces the amount of trusted code (TCB) and also the number of potential violations.

30. 7. It promises end-to-end integrity guarantee by maintaining the integrity label that all FlumeWiki files received during installation (I={iw})
8. Additional 1k LOC for DIFC and another 1k LOC to modify Moin.
9. It prevents ACL vulnerabilities and discovers new.
10. Buggy behaviour is still implemented but FlumeWiki does not let it reveal private data.
11. 43% slower than Moin in read throughput and 34% slower in write throughput. Despite this, it is fast enough for many small wiki applications.
12. Needs further optimization (FastCGI-10x).

31. Canvas Questions How is high t-integration related to endorsement?
How does Flume handle Superuser privileges? (It’s trying to eliminate that)
What else has been done to take this research forward?
How does Flume operate as a monitor?
The latency overhead is huge, so what is the average performance penalty for this? (It’s fast enough for small wiki applications. We could use Clustering, but optimization is needed (FastCGI-10x))
Could the performance hit be mitigated by implementing Flume entirely at the kernel level? (HiStar/Asbestos-kernel improvement, new H/W support)