[Music]
welcome back to the kia ora theater at
linux conference 2022
2022. it is
uh today we've got russell coca here to
talk about
uh selinux he's mostly known for working
on nsa security enhanced linux has been
a debian developer for 20 years and is
mostly known for maintaining seo linux
packages in debian
today he's here to talk through his
history of 20 years working on ac linux
including lessons and will hopefully
inspire us and inform us about working
on major open source projects as they
start take it away
thank you
okay so it's been uh a long time 20
years working on the one project
i'll just sort of go through say in the
beginning cover the process
and
do diversions onto interesting things
along the way
so firstly uh when i attend conferences
i like to hang out with speakers who
give good talks
as a lot of people do um
usually often the the speakers are more
interested in talking to people it seems
than uh the
audience are
when i first met pete lascocco from the
nsa uh when he gave his talk about essie
linux at uh auto olympic symposium
it seemed that i was the only person who
wanted to talk to him maybe people are
scared about the nsa or something
um so i talked to him he made some
interesting points about uh the benefits
he links offers and it sounds that uh
someone something that's
debian or distribution to debian could
really benefit from
as an aside um
as this is a virtual conference uh
there's no possibility for me to have
lunch or dinner with any of you
afterwards uh if you want to
correspond via twitter or email or any
other methods you like just please
contact me i'm always happy to chat
about these sort of things
one thing to note about people giving
lectures is that there's uh usually an
element of uh project promotion involved
in uh motivation for giving a lecture
about a topic as a conference like
lca or ols etc
so um
the speakers uh will often want to talk
to people who are interested in doing
some
contributing to the project or testing
the project
it's not just a case of you know give a
talk and
go away
so when i was talking to uh people
stockholm at uh oles
uh
it didn't sound like a difficult thing
to work on uh you see the mix sounds
like a
headless singing feelings it feels
easier to do
so i said okay it sounds like a good
thing i'll put it in debian probably
take me a couple of weeks no big deal
and so he just sort of looked at me
it was quiet and he said
it's a good idea you should do that
i later learned this is uh the way he
looks at someone when uh he thinks
there's something uh that wasn't well
informed
but it's not his benefit to uh
educate them on the issue
so end up i took about three months to
get
essie linux
basically working on my own systems
and
about a year to get it working well
enough for other people to use
so it was much harder than i expected
uh it turned out that not only was the
the usual
effort involved in getting a new package
in or new packages into debian
uh there was also some core packages
such as the login utilities uh
the the uh pam system for authenticating
users crime etc had to be uh changed
which for a while to maintain my own
versions of these things
and also policy button to allow uh
everything that happens which i'll talk
about later
as an aside uh one of my pet peeves is
when i talk about these sort of things
and people go oh easy linux is really
hard to use uh because it took russell's
uh a year to get it working
well it took me a year to get it working
well enough that other people would do
with almost no effort that the hard work
is involved in getting software to the
stage that other people can just uh
install whatever work
so se linux yes there are issues some
aspects of it that require some effort
for the to use but you have to do the
hard things that i've done
now one uh lesson uh i've learned about
projects for long term
is the value of documentation um
only see linux like um pretty much all
projects uh there's a lot of scope for
improving documentation
and
good documentation helps developers as
well as users even experienced
developers
you'll often
not be able to memorize everything
that's involved in it there was one
stage when i had pretty much memorized
all the essay linux policy the policies
was there's a set of rules that
determines what each program is allowed
to do
but it's much more complex now than it
was then because there's more programs
supported
there's been more corner cases
discovered of the operation of these
programs
so no one can really memorize everything
and
documentation is useful even people who
are
experts the best time to start writing
documentation is when you join a project
when you're an expert on something then
everything seems obvious and
it's hard to determine which of these
things seem obvious to me are things
that would not be obvious to other
people whereas someone who's just joined
there are some things that are not
obvious them and as soon as they learn
they can just document it usefully and
provide a real
improvement documentation for the
benefit of all the other users
and uh also documented writing
documentation doesn't require uh much
coding skills there's different types of
organization of course the use
documentation doesn't require much
cutting skills there's also uh
documentation on the bill process etc
which requires some coding skills but a
lot less than actually changing the code
and i encourage anyone who wants to
contribute to a project but doesn't uh
think they're up to the coding in
question to look into these areas
and also there's wikis for all the
different distributions of linux which
can be improved a lot
as an aside uh arc linux has a really
really good wiki a lot of people done
some great work on there
devin wiki is quite useful
but
he's not up to the level of arc so um
if people could improve that that would
be really good it's something i try and
spend some time on when i can
now um with any sort of major project um
no one is going to be skilled enough to
do it without doing it before
with uh ese linux for example the nsa
people who are the original core
developers
they had worked on other similar
projects before there were a number of
other uh systems for other proprietary
unique systems i believe there was a
trusted i-rex there was a trusted
solaris and several other commercial uh
operating systems which had the security
features that uh s links offers
and they came from the background of
having done that before and just doing
it again
which in some ways made it easier for
them but also in other ways uh perhaps
made a bit harder because the way that
the type of changes that will be
accepted by these commercial
distributions are quite different from
what would be set by linus
so there were several different versions
of these things uh
before it got to the stage of uh having
code that linus would accept
so if you're going to work on a major
project um
if you want to
do what i uh initially signed up to do
i thought it would take two weeks
that's
a lot of work and
to do
to think you can do that requires
stiffening overstating your skill or
understanding the defeat of the project
or both
a better plan is to
look at a smaller part of the project
so in retrospect i could have been had a
more accurate assessment situation and
said okay i'll get the kernel code um
uh set up in patches that against the
debian kernel so other people can then
work on some other areas and that would
have been a realistic thing to achieve
and then i could go okay let's get the
login process going
uh we're saying i'll just do everything
and it can't be that hard
it wasn't very realistic
uh it ended up but i had enough spare
time and energy
to
do it and learn all the skills i needed
but
that wouldn't necessarily be the case
for anyone who might want to
volunteer such things
and
one of the issues about selena is
because it's a security system that
covers
um pretty much all aspects of the way
programs run
uh
the process of writing the policy the
policies the
set of rules determine what each program
can do
requires
understanding what all the programs do
and not many people have that little
understanding and the only way you can
most people can get it is by writing
such a
set of rules
so uh
while the process of for example log
into a system might seem simple
it's actually more complicated than you
expect you have the
pam system pluggable authentication
modules that can run extra programs to
do various tasks
and then
the way these programs interact is more
complex than most people expect
one example is
there's a
set uid root program that's launched by
pam to check passwords
and um it made sense to have this
run on this linux system even if uh
you're authenticating uh via a root
process
and um
this um the code wasn't written that way
initially it was written that said
if
is zero then we'll just read the shadow
file if not then we'll um
run this set ud program
and what we want to do is have this
program not only be set uid but also uh
have a domain transition for different
selenium security context
so that the calling code even it's
running as root won't have the ability
to read the shadow password file
and a lot of little things like that
resulted in
ongoing work to uh maintain the patches
going forward
which uh wasn't seen uh
you know before i started working on
this
now the history of s linux so the first
version of selinux which i never
actually used
relied on
structure changes to the exc2 file
system
and this is the same this was done for
these the commercial museums i believe
so basically they found some unused
space in the inodes and use them for
indexes into a list of security contexts
so you map the google chronic switch
file to this inode entry
um that worked for commercial unit
systems and that was something that
linus
and the
other people involved in ec2 would never
accept
and also something that would never work
with um
well
would not easily at least work with
other file systems
so if that
system is going to be used you need to
have a similar patch for every fast and
supported and for every fsc program fsck
program etc and they'll be a huge amount
of work going forward
so the second version had a database
stored in root directory which is run by
the kernel
and another thing that uh one thing that
always gets rejected by the kernel
maintainers is having the kernel
open files directly it's almost
universally rejected and definitely
having the kernel
open a database file and do database
operations on it
that would be probably
even
more worthy being rejected
so uh but that got rejected as well
um
also uh one of uh linus's criticisms of
basic limiting this stage was that it
wasn't designed to work with other
security systems
so the uh aim of the nsa people was that
uh se linux does everything you you
should want to do in terms of uh access
control
uh as i said
i'm not going to speak much about the
way eclipse works i've spoken about it
before there's various uh youtube videos
of people who watched about it before
uh this talk is all about the villain
process uh i encourage people to read
those books about it as well over my
shoulder you can see uh some books i've
got on display
there's lots of documentation on these
things
uh but uh so here i'm here to talk about
the development process
so um
one
one sort of difference of opinion among
developers was that uh the nsap will
believe that
uh se linux is something everyone should
use does everything you need you don't
need to have another mantrax control
system whereas uh lunas uh almost always
believes there should be alternatives
and for everything you should uh might
want to do there should be another way
of doing it
so this is a fundamental difference
opinion here and of course
lunas gets to make the decision
so uh that means the colonel patches had
to all
change
to uh meteorologist requirements
so this resulted in the development of
the lsm the linux security module
project
and so lsm is a set of interfaces the
kernel for various action control
methods
and that means that
after you have lsm patched in
it can then call any other security
module that can do different things
these things
so the initial
development of lsm was with s linux and
app armor
so app armor is a file name uh based
access control system and it's designed
to
only restrict certain programs
so for example in debian you have nappa
set up this that
is fairly default which uh restricts
programs like apache which is a useful
thing to have but doesn't restrict
everything else whereas the way selinux
works is it's based on
reproducing accessifier inodes so a file
is renamed that doesn't change the
access the file
and files are labeled when they created
and uh not labeled any other way unless
you explicitly try decide to relabel
them whereas just based around fire
names so there's different uh approaches
to security
and so the developers were the other
developers who were working on lsm
and so initial uh
support of lsm that was uh those two
systems that were included in the kernel
patches
and
then
also
casey developed smack
which was
sort of inspired by selinx
and
permitted by the lsm so when clsm
interface are in place and you might
write any security module feel easily
and now there's a heap of them uh
there's uh
i haven't even kept track of how many
there are
and the lcm interface i think has been a
really good thing for linux and linux
security
and um
this is one example of seo linux having
given real benefits for security to
people who don't even want to don't even
like spss linux
so even if you don't want to use s linux
then you've got choices of app armor
smack and other things
which wouldn't have been there if it
hadn't been for the se linux kernel
development and the process iteration to
meet linux's requirements
so in the final uh release of s linux uh
we're using etc for the file labeling
and that's what uh is being used today
with uh no plans for changing so now
there's a security
namespace for examples for racy linux
and for other things
now for the policy development the the
policy was
sorry my monitor's
wobbling contraction okay uh the policy
was originally written in m4 macros
and uh
there was uh
the way it was distributed was uh as
policy source files which were then
compiled on install
because uh with the way it worked um to
make any change you had to do a
recompile
and um
for most cases se linux
isn't
easy to use unless you have the ability
to train your own policies
so you can build a policy for a
particular use case then roll it out to
100 machines thousand machines
uh without changes that works fine
but actually if you want to um develop
the creation of your
systems
having a
distributions policy with no changes at
all probably isn't going to work that
well because there'll be some corner
case that you have that they didn't
cover you're running a demon that uh
the distribution developers uh didn't uh
plan on you running
your uh installing things in different
directories or there's some other uh
difference
with demons like apache apache is
extremely configurable
and
writing policy to cover all possible
configuration options this isn't really
possible given that apache has
shared objects to plug in for many
different programming languages and they
all have slightly different security
requirements
so
to use easylinks you require
some local configurations in the first
releases of esa linux that required
compiling the source the policy
which
in the long term wasn't a good option
so
the the version that was uh developed uh
later on
uh i think they came in to be um
the first release fedora core five uh
was the uh modular policy which has
dependencies in the policy files
and so basically you can load a you have
a module defined which
specifies which
types in the policy it depends on and
they can be loaded into the policy first
types defined
types are the labels for
processes files or other objects
accessed by the
system
and so
for example you had a
policy module that
related to the apache policy you would
say you depend on the httpd unscore t
type
and then you could load whenever the
parties policies loaded
now speaking of the
changes made
to other things foreign
because of s linux
there have been a number of daemons
which have been changed because
so with selinux controlling
the
use of
write executed memory uh there's been a
number of cases of demons which uh have
requested executable stacks and
requested
right execute memory mapping which never
actually needed it
and essie linux policy made these
problems more obvious so then they could
be fixed and
people who don't use s linux could then
have these programs run without
accessible stacks without the ability to
write and execute memory
and the
uh security would improve without them
even knowing it without using selinux
and also uh
there are choices uh made available
so uh for some kind for um
programs that use just-in-time
compilation
which includes a lot of interpreters as
well as some
things you might not expect
such as
one stage the clan maybe anti-virus
scanning
system
used
just in time compilation as uh part of
its optimizations
these things can be with this elites you
can turn them on or turn them off in the
policy
and so in that case might mean your uh
antivirus and runs a little slower
if you have plenty of cpu power and are
concerned about security you can do that
or if you have
a huge amount of email to scan the
viruses
and uh you're not sorry about security
you have the choice to
allow the just-in-time compilation
and in both cases uh it's something that
the developers upstream were aware of
and could then write their codes to
support both cases
so if someone uh who doesn't like ac
bluemix is running a clan movie they
could use a different security system
one of the other lsms that also
restricts uh executable
invitable memory
and uh
claim iv would work with it which is a
nice feature
another example is
when i was in japan one time i had some
friends uh show me a program that uh
wasn't working with their siblings
policy
this program to allow um
type in kanji
and the way it would work is you'll be
using wordpress or any other
text editing program
and you type in words in romanji that is
the latin alphabet we use
and then it would prompt you
with kanji letters to replace some of
these romanji words
and uh the way it worked is um the demon
that does the translation between uh
romanji these words we could type in our
keyboards
to the kanji characters was via a um
named pipe under slash champ
also known a unix main socket and under
temp
i don't mean of course that
basically everything you typed on such a
configuration of japanese system would
be sent to this
name named pipe under slash champ
and therefore if the demon hadn't
started
and a hostile process
had created a name pipe under that name
you'll just see everything you type
which could be a major security issue
now it is possible with selinux to make
it
slightly less insecure
and that means that instead of having
any programming system being able to
create that uh
unix main socket you could be restricted
to only
processes in certain contexts
but that could still be a problem so for
example if you have a multi-user system
with multiple people running in the same
security context or similar security
context
running word processes
one of them could if the demon wasn't
running start their own process and
proxy the other user's data and see it
all
so in this case i said no we can't write
esthetics policy to
allow this program to run as a daemon
and listen to a unix domain socket in
slash champ we need to find a better
place for maybe something under the
fastest lube
and
avoid these problems so for example you
have a directory under slash lib that is
only writable by
root or by
a user id just for that demon
then
most the problems
of this potential processing data go
away
now um when i first started um
getting something to work on debian
there was at the time a practice of
having uh debian kernel patch packages
so the idea being that you could get the
uh standard debian kernel source that
was uh used producing the um
official
debian kernel image packages
and uh patch it uh for whatever you want
to patch it for and then build your own
kernel which is the same as the debian
one
apart from the change that you need to
have
uh as opposed to getting a upstream
kernel from kernel.org and then missing
out on the
debian patches which might be something
you actually need
so i maintained uh deviant kernel
packages for uh current patch packages
for se linux and uh then later on i
separate packages for lsm and s linux
for a number of years while it was going
through the process of meeting linux
criteria
and until we
until linus was satisfied and just got
included in the
upstream kernel
so in retrospect um
there could have been uh some time and
effort saved uh
by the nsa people and by everyone else
who's involved in working on it if
there'd been fewer uh implementations of
labeling
um
the initial decision to just
use one use field in the xt2 file system
that wasn't necessarily a bad thing
because
they wanted to just quickly uh get a
prototype going
and uh i guess that's the stage perhaps
uh it wasn't certain how we'll be
supported and what the future would be
um but uh later on i think perhaps etc
could have been predicted to be a better
a more supported limit to luna's
solution
um as an aside um
after we got ac links included upstream
and included in debian and
centos
lunas apparently still didn't uh like
easy linux at all
um one time he met with me at lca to
just um tell me that uh he didn't like
se linux which was an interesting
experience
so
one of the things that i'm
known for uh is running what i call
excluding play machines
and this is a machine where i set up
root as the
guest account
and
allow people from all over the internet
to log in and just try it out so
basically it means having no usable unix
permissions use access controls and just
using selinux
so that's been uh fun um
i guess
it's a possibility you could describe
this as a form of trolling
um
it's a better opinion on how it works uh
i think it was a useful project in terms
of testing as you linux
and
teaching random people about it and also
learning about
how security works
and along the way uh there are a number
of times when uh
uh other people uh
gained more access than expected to the
machine
and told me about it which is good
so the first version of the play machine
um
didn't have a separate label for the
shadow file
and then anyone could read it and um
that combined with fact that the
password wasn't a
um if you were to guess one for a
machine uh
i was a bit of a fan of sushi at the
time so i've named the made the
the administrative password raw fish
and so two people uh emailed me that
password within uh a couple of days of
premium machine online which was um
amusing
um
one thing that uh this that incident
maybe think about is the fact that
software design reflects the aims and
thoughts of programmers
and
in this case the nsa people who did the
who did pre-order all policy for the
first uh releases of s linux
their aim was not
reproducing next controls of unix
permissions their aim was to uh isolate
uh users
uh after they've been authenticated uh
by using submissions
and so pressing the shadow password file
wasn't really an issue for them they was
going
assumed that um that would be dealt with
by uh used commissions
and so i was running running a roof as
the guest account uh was very different
from what they were planning so
it didn't work so well but on the other
hand there are a lot of demons that
run this route
and um
we don't want those to be able to uh
access the shadow file it's a fairly
standard thing for a demon if compromise
is root so you try and read the shadow
file
so this is a change that needs to be
made and it was made it would have been
made sooner or later and it was made
sooner because uh i had some people
email me the
administrative password
so another problem found with the bias
configuration i found with the estimates
uh confession initially was that the
bias definition devices were uh
world-writable with no special labels
so
i was running a machine that
had
devices for rewriting the bios
which was uh in eprom i believe
and um
i was informed about this after someone
had
written random data to us
so uh
i was
unsure whether the machine would have a
boost again but it turned out it did
boot so that was uh nice
and something to check for future uh
security systems
another interesting uh lesson learned
from the
play machines
is
when i was running one at fosdem it's a
european
free software conference
on the debian stand there there was a
debian
machine running a old apple macintosh
demonstrating debian on the m68k
architecture
and the demonstration ends up being
demonstrating how well the machine can
be at a ssh running state should be a
terminal emulator to log into the play
machine uh while one guy was spending a
lot of time trying to compromise
and he ended up winning
he discovered that the crontab program
uh launched the editor with uh excessive
permissions
and uh
uh vi which is the default editor allows
you to launch a shell so the shell will
also have uh excess permissions and that
he was able to access files you should
get access and uh eventually gain your
elevated privileges
so i changed this women's policy
immediately after that to um restrict
the next of the quanto program
but this is good it was uh something
that hadn't been considered uh this is
more secure
and uh even uh non
play machine configurations will be
slightly more secure because this
and nothing to to learn about this is
that competition drives interest and
this is uh
the amount of effort that guy spent on
testing the machine you couldn't pay
someone to do that
this is just he wanted to show off
how skillful he was and he succeeded
his friends then
took a photo of the slides when i was
giving a talk about linux mentioning
that how he did it just to uh as his
prize i guess
so um yeah that uh worked out well for
everyone uh i improved the policy we all
learned about uh more about security in
linux and that guy got the um honor of
um
finding a floor in essence policy was
being used at the time
and there also were a lot of people who
thought that practice and people just
didn't get concept
uh one was a guy who was um wrote a
script to just uh kill the shell of
every other user who logged in on the
guest account
which isn't um cracking it this is a
dial service attack and only worked
against people with the same access as
him which was the guest user
and so of course i could log in and kill
the scripts and
didn't
so that wasn't
effective
um
also i noticed he was trying to
forward exploring connections
so i changed the stage connection to
configuration to allow x11 forwarding
and then uh ran the x logo program on
the screen
and uh
he
tried to deny it was there
i said okay do you give me permission to
uh read the keyboard
of the person who has this x logo uh
display on it on their screen with this
person which is not you i guess
and then he logged out midway
which is amusing so anyway
uh you need to be fairly combative to
run a a challenge machine like that
and
because there was a lot of
hostility uh the result from us
and a lot of amusement
and i think that for general um
uh computer security staff uh that sort
of attitude uh helps because um
there are a lot of um crazy people out
there
and a lot of people want uh arguments
and things
but it's um also amusing
um
there are there have been a lot of
conspiracy theories about the nsa
none of them have
any truth as far as i'm aware
the nsa people
smart programmers
who are very studious um not very
exciting
yeah there's no
james bond stuff happening or if it does
it doesn't involve me
but you know working on some interesting
code
hang out with people who
know all about computer science
and have interesting stories tell about
other programming tasks
so in terms of hanging out with skilled
programmers and leading about computers
s linux has been really great something
i can highly recommend to other people
if you're after james bond stuff
i don't know what to do because it
hasn't involved me
about 10 years ago people stopped
telling me about uh conspiracy theories
which is um in a way a relief because
it's just nothing to do with me
but also um makes things less exciting
i guess
they probably still believe the kind of
stuff but um doesn't involve me
overall um
working on s linux has been a great
experience
my skills have increased a lot because
of it
a lot more than i
expected when i first
started on it
working on a big project whatever the
big project is
you will learn a lot
and
especially if you
end up in a sort of a lead role in it
um but even if you're not in one of the
league roles uh every for every project
there is a lot of things to learn and uh
you can just choose a project that fits
your skills interests and whatever you
just use yourself
and join us
you learn interesting things
have some fun
some parts are boring of course that's
the life
but generally it's a good experience and
then you can
go to lca and give talks about it
okay um
so i've pretty much covered my uh
material uh for now so should we go to
questions
yes hello uh thank you so much for your
talk that was really interesting to hear
that kind of history
um we've got one question but as a
reminder for people if you have more
questions chuck them in the questions
tab we are running on a delay so uh
getting them in earlier is better so
that we can actually see them
um
that was really cool
the first question we have is have you
been involved in any seo linux
applications for containers
um no um
the containers things are supposed to be
been done by red hat i think and that
hasn't involved me um i was um
one thing i did was i gave a paper for
uh auto link symposium about
running selinux on
small devices so i initially got s linux
working on the media operating system
for the ipac and the ipac had something
like
16
megabytes of storage and 64 megabytes of
ram or maybe the other way around i
can't remember i've got a paper on my uh
website that gives all the details but
anyway each kilobyte counted and so
we're going to paper about uh you know
how to
get these things smaller
having uh four kilobyte uh programs so i
didn't have to have an extra block of
disk space used for
the different things
and uh demonstrating that uh in that
constrained environment easy linux was
definitely viable
and uh describing the things needed to
be done to get it working
and uh this ends up as uh i don't think
uh my code was copy but i think it ended
up as being inspiration for the uh
android s linux stuff because the first
android devices were like um
256 meg of ram and um about
512 megs of storage or something and at
the time that easy linux was done in
android i think was up to about a gig of
ram
so it was way way bigger than the ipac
so having demonstrator that works on
ipac means that
obviously s linux and android was not
gonna be a problem at all and so i
believe that pretty much all android
devices now using se linux so that's
great uh makes a little bit harder for
pool tacos because those machines are in
hostile environments and
often don't get updates
so we've got ongoing problems with
android device being essentially
abandoned by the manufacturers about a
year after they're manufactured mostly
so um it's nice that s linux will make
it a little bit harder for
households parties to attack them
that's so cool
um
oh we have two more questions uh we've
got first one is what are your thoughts
on binary policy and distros and
associated issues
like issues updating policy when setting
persistent balls if there's a gitlab
issue tracker
to stop people shooting themselves in
the foot should these districts at least
be disabled
okay um
i can copy this into chat if you want
it's a long one yes that'd be good um
okay if a persistent ball is set then an
update to policy i think
should um
not change that
and
but this is
just a regular um
operating system bug
if it doesn't if the bug
uh if it doesn't do that already then it
should do that um it could be an
upstream bug um
yeah um i don't think uh my thoughts are
actually really relevant on that issue
of you know the way you expect
distribution to work is that you make a
setting and the setting remains
and
code should be changed to make it happen
yeah i realized i misread that so that
made sense why you were confused um
uh the second one's also quite long
we've got
what are your thoughts on divergence of
distro policies and the rift policies
and issues thereof is there a solution
some policies are overly permissive and
with no deny rule there's no way to
override but the work to generate one's
own policy for the district is large
yeah okay so
the two main policies that i'm aware of
are the
reference policy which is the upstream
one managed by theresa's and uh the red
hat one
and we have one uh diverges a bit they
have some different names for the
interfaces
an interface in policy is
vaguely comparable to a function called
a programming language
except that the difference is uh it's
not a function it's just a
set of rules being hooked in
and yeah i think this should be uh less
divergence
um now in terms of the no deny rule um
the way uh s linux works is its uh
defaults not everything sorry that's not
permission is denied and so if you have
a policy distribution which
is excessively received then
that makes it very hard for you
there have been a number of changes over
the years one thing that's worth
thinking about is
when essay links was first released you
had two roles for these logins sysadam
and user which have
obvious meanings
and then one of the first things i did
was
wrote macros because a time all policies
macros
to allow
an arbitrary number of other roles
and so
this was initially done when i had a
play machine running on debian stand at
a conference
and someone asked me through password
and i told them
and i didn't realize that uh he wanted
he he asked root password so he could uh
store his important files uh under an
account where no one would mess with him
which he thought would be root
uh and didn't realize uh i would be
telling people to um tie typing r minus
rf as root and observe that nothing bad
happens
so his files all went away and he wasn't
that happy about it
um
in retrospect he should have just
mentioned what he was aiming and anyway
so i then uh create a policy which
allowed an arbitrary number of roles and
had that running for a while um
but the um
the
policy aim of having different user
roles became increasingly difficult to
manage as
the
login systems became more complex and
the demand
became greater so it used to be that you
just log in and you would just uh have a
fairly
you know program running with a manager
you'd have some externs and things i
mean one other stuff now you've got um
you log in you've got a uh gpg agent run
by your distribution when you log in
you've got maybe an ssh agent uh in the
background you've got um the pulse audio
daemon running audio in the background
and all these things have been managed
and it comes very hard to do
and also uh providing uh probably not a
lot of benefit so um what most people
are doing now is running uh the used
login sessions in the unconfined uh
domain
and uh that's very impressive and might
be what the
original person asked that question was
referring to
in that case you can change your
configuration to have your user login as
uh
the user runs for you
identity
and that means that probably some things
you want to do won't be
allowed and
it's just a very difficult problem to
solve
given that you have people who want to
do all manner of things on the user
account versus people who would have
certain things restricted or isolated
and
there's no
one good solution that's going to solve
these problems
um
one thing with
android having i believe android has a
separate unix uid for each application
and that sort of approach uh can give
real benefits without uh going down this
path
and so maybe we should be considering
other ways of uh running regular user
stuff uh on unix sub sessions
there has been talk of
i think it was a talk at a previous lca
about
using
systems like docker for
running
various desktop apps under a user
session and that sort of thing can
provide some real benefits i think
and without making it too hard to manage
and
also another approach is that the tales
approach of having
separate sessions for every program
that also is in its own way very
difficult to use
um
the problem the problem with security is
always
balancing out with usability and if you
say uh i want to do everything possible
and also have
everything secure that's probably not a
truthful goal
i'm gonna cut into this i feel like you
have an entire different entire another
talk here
uh
i only talked three hours literally
uh this is a really good conversation
thank you so much for this um we do have
a
couple more questions including a
conspiracy theory uh question that i
will drop into the post talk uh
chat kiara
kia ora theater
i said that very wrong um
yeah thank you so much for talking with
us today
thank you
our next talk is visualizing and tracing
requests through a cluster integrating
open tracing into openstack swift with
matthew oliver
and that's a 225
att so in like 10 minutes