| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Extremely cruddy implementation:
- I'm still unclear on how to represent the advice function:
- How to handle errors when loading user configuration?
Currently I refuse to start.
- Whole function? More errors to handle in header and so on. What if
the function is renamed?
- Just body? Needs more structured editing support.
- Lots of duplication, particularly between the permissions in the menu
and the permissions screen.
I don't know how to show the hostname at the time of connect() or
bind(), so networking is going to remain a boolean for now. It's also
unclear what effective constraints we can impose on what gets discussed
with a specific hostname. Everything outside the computer is out of
one's control.
One trick I learned is for consistently grabbing ASan logs on abort:
It's always safe to redirect stderr with ncurses!
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Zero guarantees of compatibility at this point.
|
| | |
|
| |
|
|
|
|
|
| |
I _think_ I don't need to gate other socket calls; you can't do anything
without bind() and connect(). And they should be good places to dump
more precise details later about the kind of server or client connection
being attempted.
|
| |
|
|
|
|
|
| |
In the process we now also have a mechanism for Teliva to overlay errors
while apps run. Might make sense to make that available to apps as well.
But I'm starting to realize that any app access to the Teliva areas of
the screen is fraught with risk.
|
| | |
|
| |
|
|
|
|
|
| |
Our sandboxing model is a blunt caricature, just two booleans. But let's
see how far this gets us.
Still doesn't persist, and definitely has no effect.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Current plan:
- two booleans to gate file and network access, respectively
- false shows as green, true shows as orange
- if _both_ booleans are true, then both show as red to indicate that
there are no protections.
|
| | |
|
| |
|
|
|
|
|
|
| |
It looks like attron doesn't actually enable colors near 256, even
though https://linux.die.net/man/3/attron suggests it does.
> COLOR_PAIR values can only be OR'd with attributes if the pair
> number is less than 256.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Put stuff people messing with Teliva apps are likely to need above the C
interface.
The state of documentation for Teliva app creators is still quite poor.
All they really have to go on is the example apps.
|
| |
|
|
| |
It should now be easier to diff against the Lua 5.1 sources upstream.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This isn't necessarily for sandboxing, but they don't really work right
now in the presence of ncurses, and it seems better to not include
broken stuff. Maybe we can get them to coexist with ncurses down the
road.
|
| |
|
|
| |
It's not really an ideal use case for Teliva.
|
| |
|
|
| |
Again, too difficult to sandbox for now.
|
| |
|
|
|
| |
Stop interpreting arbitrary Lua code when loading editor state. We don't
need that power or security risk.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
I'd originally thought of allowing policies to be influenced by
arbitrary code. But that may be overkill:
- it's probably not a good idea to allow policies to read/write from file system
- it's even less a good idea to allow policies to access the network
- particularly since it's difficult (error-prone) to distinguish GET/POST in arbitrary protocols
- once you allow file system and network, you're pretty close to owned
So let's first focus on the simplest policy, the one that is easiest to
secure. We'll add capabilities to policies as we gain confidence we can
secure them.
|
| | |
|
| |
|
|
|
| |
Too hard to sandbox. Maybe we'll get back to it if there's some use case
only it can satisfy.
|
| | |
|
| | |
|
| | |
|