John Nemeth | 2 Sep 2006 11:37
Picon
Favicon

Re: SE Linux vs SE NetBSD !!

On Jan 20, 11:21am, "Travis H." wrote:
} On 8/29/06, John Nemeth <jnemeth <at> victoria.tc.ca> wrote:
} 
} There's lots of cases where the perimeter is breached.  A big one is
} road warrior
} salespeople who bring worms in on their laptops, and Windows users who
} execute malware.

     This is where things like Cisco's NAC (Network Admission Control)
comes into play.  Basically, it prevents machines from connecting to
the network if they aren't running the latest patches, anti-virus, etc.
(whatever you put into your policy).  It can either block the machine
completely or quarantine it in a subnet where it can only get updates.
There may be other products that do similar things, but I'm not aware
of any.

} > Of course, for
} > real security, you shouldn't be using plain NFS.  Also, we don't know
} > when somebody might breach the firewall or the firewall administrator
} > might make a mistake.  Defense in depth and all that.
} 
} All true.
} 
} What options exist apart from NFS and SMB?  I think there was one
} called coda, and AFS, and Linux has sshfs (requires a kernel module on
} the client)... anything else?

     Sun's version of NFS can use secure RPC.  There may be other
options in NFSv3 or NFSv4.  Another thing would be to use IPSec.  Of
course, there is the issue of authenticating users and making sure they
(Continue reading)

Travis H. | 3 Sep 2006 00:26
Picon

OT: authenticating users, was Re: SE Linux vs SE NetBSD !!

On 9/2/06, John Nemeth <jnemeth <at> victoria.tc.ca> wrote:
>      This is where things like Cisco's NAC (Network Admission Control)
> comes into play.  Basically, it prevents machines from connecting to
> the network if they aren't running the latest patches, anti-virus, etc.
> (whatever you put into your policy).  It can either block the machine
> completely or quarantine it in a subnet where it can only get updates.
> There may be other products that do similar things, but I'm not aware
> of any.

I think you could write this up in a script using nmap and authpf.

> Of
> course, there is the issue of authenticating users and making sure they
> don't try to fake the credentials of a different user.  I think some of
> the other options are better for that.

Yeah, well nowadays there's so many PCs relative to the number of
users, and it's reasonable to assume one user per workstation.
I think Kerberos is designed with this assumption.  Certainly
network security devices like firewalls are.  A person with
physical access can probably get any other user's privileges
anyway.
--

-- 
"If you're not part of the solution, you're part of the precipitate."
Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066  151D 0A6B 4098 0C55 1484

YAMAMOTO Takashi | 3 Sep 2006 12:03
Picon

Re: Upcoming security model abstraction

> Hi,
> 
> Recently I've been working on abstracting NetBSD's security model
> to its own set of kauth(9) listeners. There's code for the listeners,
> as well as initial diff for replacing the KAUTH_GENERIC_ISSUSER
> requests with something more specific.
> 
> Due to it being spread across multiple files and quite big in size, I've
> placed it all online:
> 
> 	http://www.bsd.org.il/netbsd/secmodel/

thanks for doing that.

- please make "ISCOPE" a proper reverse-dns strings.
  they are in the same namespace as KAUTH_SCOPE_xxx.

- i don't think __CONCAT magic in secmodel_start() is a good idea.
  at least, make it SECMODEL_START(), as it can't be a normal function.
  also, can you move param.h changes into init_main.c, as it's only place
  these definitions are used?

- why arguments of authorize wrappers are of void *?
  it seems that you (almost?) always need to cast like (void *)KAUTH_REQ_xxx.

- please make files have some prefixes.  bsd44.c is a way too generic name.

YAMAMOTO Takashi

(Continue reading)

Travis H. | 3 Sep 2006 12:31
Picon

Re: Upcoming security model abstraction

On 8/24/06, Elad Efrat <elad <at> netbsd.org> wrote:
> Due to it being spread across multiple files and quite big in size, I've
> placed it all online:
>
>         http://www.bsd.org.il/netbsd/secmodel/

This directory seems to have disappeared.

BTW, I'm willing to help at the design level of BPG and a secure update
model for packages/ports/etc.  I don't think I'll have time to help with the
implementation though.

I don't know what the licenses on the modules are, but consider using a
HLL for _userland_ security tools that interact with the network or process
untrused data.  The opportunity for a variety of implementation-related
vulnerabilities is thereby avoided.  If you use a widespread package for
the low-level implementation like openssl (isn't that capable of doing
signatures and it's already in userland isn't it?) then you can avoid all
the hassle and error-prone bit-diddling and spend your time on
protocol-level stuff, often with an order-of-magnitude reduction in
lines-of-code.  I use python myself but hear good things about ruby
from the bilingual people I know.  If you want to get really crazy,
consider a (mostly) functional language like ocaml.  Then you
completely avoid worrying about flow-of-control and the subtle
problems that can arise therein (e.g. the problem of testing every code
path, the hidden bugs that lurk in infrequently-used code paths,
off-by-one errors in loops and getting the sense of the test wrong).
--

-- 
"If you're not part of the solution, you're part of the precipitate."
Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/
(Continue reading)

Elad Efrat | 3 Sep 2006 16:12
Picon

Re: Upcoming security model abstraction

YAMAMOTO Takashi wrote:

> thanks for doing that.

No problem.

> - please make "ISCOPE" a proper reverse-dns strings.
>   they are in the same namespace as KAUTH_SCOPE_xxx.

Okay.

> - i don't think __CONCAT magic in secmodel_start() is a good idea.
>   at least, make it SECMODEL_START(), as it can't be a normal function.
>   also, can you move param.h changes into init_main.c, as it's only place
>   these definitions are used?

Will change to SECMODEL_START() and move to init_main.c -- I've been
planning on removing it from param.h anyway, it can be really annoying
to rebuild everything. I'll also add a secmodel/secmodel.h to include
from init_main.c, that in turn includes bsd44.h et al.

> - why arguments of authorize wrappers are of void *?
>   it seems that you (almost?) always need to cast like (void *)KAUTH_REQ_xxx.

Yes, that's ugly. As you can see, I've made it all into enums, and I'll
be changing these soon to remove as many casting as possible. Working on
it. :)

> - please make files have some prefixes.  bsd44.c is a way too generic name.

(Continue reading)

Elad Efrat | 3 Sep 2006 16:21
Picon

Re: Upcoming security model abstraction

Travis H. wrote:

> This directory seems to have disappeared.

Sorry about that, it's back online.

> BTW, I'm willing to help at the design level of BPG and a secure update
> model for packages/ports/etc.  I don't think I'll have time to help with
> the
> implementation though.

Cool. There were two folks who were looking at the code a while ago in
an attempt to revive the project -- contact me off-list and I'll give
you some more info.

> I don't know what the licenses on the modules are, but consider using a
> HLL for _userland_ security tools that interact with the network or process
> untrused data. 

At the moment, to really allow 100% dispatching to userland of
authorization requests (I'm assuming you're talking about security
modules?) we need two things: first, a lot of our locking schemes don't
make it easy to go to usermode in some cases where kauth(9) calls are
made. We'll have to work. Second, we'll need a generic kernel-userland
communication mechanism, which can be used both by kauth(9) for the
above, and Veriexec to do signature handling stuff.

Until we have these two -- and it's going to take a while :) -- there's
still some time.

(Continue reading)

Elad Efrat | 3 Sep 2006 17:07
Picon

Re: Upcoming security model abstraction

Thomas E. Spanjaard wrote:

> I suggest secmodel/secmodel_bsd44.c as is common practice (like e.g.
> kern/kern_*).

That means we'll have to use files with names like
secmodel_<model>_foo.c which is starting to get ugly.

-e.

--

-- 
Elad Efrat

Hubert Feyrer | 3 Sep 2006 16:12
Picon
Favicon

Re: Upcoming security model abstraction

On Sun, 3 Sep 2006, Elad Efrat wrote:
>> I suggest secmodel/secmodel_bsd44.c as is common practice (like e.g.
>> kern/kern_*).
>
> That means we'll have to use files with names like
> secmodel_<model>_foo.c which is starting to get ugly.

secmodel/sm_bsd44_foo.c ?
Or put the security models into src/sys/kern/secmodel_bsd44_* ?

Just some ideas...

  - Hubert

Elad Efrat | 3 Sep 2006 17:15
Picon

Re: Upcoming security model abstraction

Hubert Feyrer wrote:

> secmodel/sm_bsd44_foo.c ?
> Or put the security models into src/sys/kern/secmodel_bsd44_* ?

Personally, I think '<model>_<function>.c' is elaborate enough.

Consider 'bsd44_suser.c' or 'bsd44_securelevel.c' - should make it
clear what these are; if this is still too 'vague' (and seriously,
take a moment to think where this is really effective), I'll go for
'secmodel_<model>_<function>.c'.

-e.

--

-- 
Elad Efrat

YAMAMOTO Takashi | 3 Sep 2006 17:10
Picon

Re: Upcoming security model abstraction

> > secmodel/sm_bsd44_foo.c ?
> > Or put the security models into src/sys/kern/secmodel_bsd44_* ?
> 
> Personally, I think '<model>_<function>.c' is elaborate enough.

bsd44.c can easily conflict with something from other unrelated subsystems,
if one choose the same naming scheme as you.  eg. bsd44 scheduler.

> Consider 'bsd44_suser.c' or 'bsd44_securelevel.c' - should make it
> clear what these are; if this is still too 'vague' (and seriously,
> take a moment to think where this is really effective), I'll go for
> 'secmodel_<model>_<function>.c'.

i vote for secmodel_<model>.c (and secmodel_<model>_foo.c where
<model> needs two or more files).

YAMAMOTO Takashi


Gmane